database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

Align GRANT/REVOKE behavior more closely with the SQL spec, per discussion

Browse Source 
of bug report #1150.  Also, arrange that the object owner's irrevocable
grant-option permissions are handled implicitly by the system rather than
being listed in the ACL as self-granted rights (which was wrong anyway).
I did not take the further step of showing these permissions in an
explicit 'granted by _SYSTEM' ACL entry, as that seemed more likely to
bollix up existing clients than to do anything really useful.  It's still
a possible future direction, though.
This commit is contained in:
Tom Lane
2004-06-01 21:49:23 +00:00
parent f35e8d8431
commit 4b2dafcc0b
7 changed files with 767 additions and 337 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
doc/src/sgml/ref/revoke.sgml
View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/revoke.sgml,v 1.29 2003/11/29 19:51:39 pgsql Exp $
$PostgreSQL: pgsql/doc/src/sgml/ref/revoke.sgml,v 1.30 2004/06/01 21:49:21 tgl Exp $
PostgreSQL documentation
-->
@ -81,6 +81,7 @@ REVOKE [ GRANT OPTION FOR ]
<para>
If <literal>GRANT OPTION FOR</literal> is specified, only the grant
option for the privilege is revoked, not the privilege itself.
Otherwise, both the privilege and the grant option are revoked.
</para>
<para>
@ -103,7 +104,7 @@ REVOKE [ GRANT OPTION FOR ]
<para>
Use <xref linkend="app-psql">'s <command>\z</command> command to
display the privileges granted on existing objects. See also <xref
display the privileges granted on existing objects. See <xref
linkend="sql-grant" endterm="sql-grant-title"> for information about the format.
</para>
@ -114,9 +115,25 @@ REVOKE [ GRANT OPTION FOR ]
C, then user A cannot revoke the privilege directly from C.
Instead, user A could revoke the grant option from user B and use
the <literal>CASCADE</literal> option so that the privilege is
automatically revoked from user C.
in turn revoked from user C. For another example, if both A and B
have granted the same privilege to C, A can revoke his own grant
but not B's grant, so C will still effectively have the privilege.
</para>
<para>
When a non-owner of an object attempts to <command>REVOKE</> privileges
on the object, the command will fail outright if the user has no
privileges whatsoever on the object. As long as some privilege is
available, the command will proceed, but it will revoke only those
privileges for which the user has grant options. The <command>REVOKE ALL
PRIVILEGES</> forms will issue a warning message if no grant options are
held, while the other forms will issue a warning if grant options for
any of the privileges specifically named in the command are not held.
(In principle these statements apply to the object owner as well, but
since the owner is always treated as holding all grant options, the
cases can never occur.)
</para>
<para>
If a superuser chooses to issue a <command>GRANT</> or <command>REVOKE</>
command, the command is performed as though it were issued by the
@ -140,11 +157,15 @@ REVOKE INSERT ON films FROM PUBLIC;
</para>
<para>
Revoke all privileges from user <literal>manuel</literal> on view <literal>kinds</literal>:
Revoke all privileges from user <literal>manuel</literal> on view
<literal>kinds</literal>:
<programlisting>
<programlisting>
REVOKE ALL PRIVILEGES ON kinds FROM manuel;
</programlisting>
Note that this actually means <quote>revoke all privileges that I
granted</>.
</para>
</refsect1>