Kiedy uprawnienia są wymienione w \ l, a kiedy nie?

Kiedy uprawnienia dostępu są wymienione przez \ l, a kiedy nie? Uprawnienia dostępu wymienione przez \ l można zmienić po przyznaniu i unieważnić:

$ createuser -EP my_readonly
$ psql development
development=# \l
                                           List of databases
            Name             |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges   
-----------------------------+----------+----------+-------------+-------------+-----------------------
 development                 | vagrant  | UTF8     | en_GB.UTF-8 | en_GB.UTF-8 | 
...
development=# grant usage on schema public to my_readonly;
development=# grant connect on database development to my_readonly;
development=# \l
                                             List of databases
            Name             |  Owner   | Encoding |   Collate   |    Ctype    |     Access privileges      
-----------------------------+----------+----------+-------------+-------------+----------------------------
 development                 | vagrant  | UTF8     | en_GB.UTF-8 | en_GB.UTF-8 | =Tc/vagrant               +
                             |          |          |             |             | vagrant=CTc/vagrant       +
                             |          |          |             |             | my_readonly=c/vagrant
...
development=# revoke connect on database development from my_readonly;
REVOKE
development=# revoke usage on schema public from my_readonly;
REVOKE
development=# \l
                                           List of databases
            Name             |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges   
-----------------------------+----------+----------+-------------+-------------+-----------------------
 development                 | vagrant  | UTF8     | en_GB.UTF-8 | en_GB.UTF-8 | =Tc/vagrant          +
                             |          |          |             |             | vagrant=CTc/vagrant

Dlaczego? Jaki stan się zmienił? Wierzę, że zdolność użytkownika my_readonly do połączenia nie uległa zmianie przez całą sesję psql (ponieważ domyślam się, że rola PUBLIC ma uprawnienia do łączenia), ale najwyraźniej coś się zmieniło: co to jest?

Pytanie boczny: jak mogę zapytać wprost, czy postgres PUBLIC w rzeczywistości nie mają połączyć przywileje (mogą one zostały odwołane - zobacz Dlaczego nowy użytkownik może wybrać z każdej tabeli? )?

Polecenia odwrotnego ukośnika w psql to skróty do zapytań lub zapytań, które przeglądają katalogi systemowe. \lKomenda wygląda na informacji pg_catalog.pg_database, w szczególności, tego zapytania:

SELECT d.datname as "Name",
   pg_catalog.pg_get_userbyid(d.datdba) as "Owner",
   pg_catalog.pg_encoding_to_char(d.encoding) as "Encoding",
   d.datcollate as "Collate",
   d.datctype as "Ctype",
   pg_catalog.array_to_string(d.datacl, E'\n') AS "Access privileges"
FROM pg_catalog.pg_database d
ORDER BY 1;

Możesz sprawić, że psqlpokaże, czego używa dla poleceń z odwrotnym ukośnikiem, przekazując mu -Eflagę, gdy wywołasz ją w wierszu poleceń.

Jeśli uprawnienia do bazy danych lub innego obiektu są wartościami domyślnymi, które tworzy je PostgreSQL, *aclkolumna będzie NULL. Jeśli zmienisz ustawienia domyślne, tak jak masz, kolumna ACL zostanie wypełniona informacjami dotyczącymi uruchomionych instrukcji GRANTi / lub REVOKEinstrukcji.

Możesz zobaczyć uprawnienia / listy ACL konkretnie poprzez jeden \zlub\dp

Jeśli przeczytasz tutaj:

http://www.postgresql.org/docs/9.4/static/sql-grant.html

Jeśli przewiniesz w dół (lub poszukasz słowa psql), możesz spojrzeć na tabelę, która pokazuje, jak interpretować listy ACL widoczne \lw kolumnie ACL lub w niej.

Na przykład:

=Tc/vagrant

oznacza, że ​​PUBLIC (domyślna rola, która zawiera wszystkie role) ma uprawnienia do tworzenia tabel tymczasowych Ti łączenia c, ponieważ linia ACL =xxxxxoznacza uprawnienia zastosowane do PUBLIC, podczas gdy rolname=xxxxma zastosowanie do tej konkretnej roli.

Ta prezentacja Dalibo powinna również pomóc w dalszym wyjaśnieniu tego: Zarządzanie prawami w PostgreSQL

Mam nadzieję, że to pomaga. =)