database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-09-02 04:21:28 +03:00
Code Activity

When a superuser does GRANT or REVOKE on an object he doesn't own,

Browse Source 
process the command as though it were issued by the object owner.
This prevents creating weird scenarios in which the same privileges
may appear to flow from different sources, and ensures that a superuser
can in fact revoke all privileges if he wants to.  In particular this
means that the regression tests work when run by a superuser other than
the original bootstrap userid.  Per report from Larry Rosenman.
This commit is contained in:
Tom Lane
2003-10-31 20:00:49 +00:00
parent 19554ed487
commit 8545482947
3 changed files with 135 additions and 67 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/grant.sgml,v 1.36 2003/09/20 20:12:05 tgl Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/grant.sgml,v 1.37 2003/10/31 20:00:48 tgl Exp $
PostgreSQL documentation
-->
@@ -66,19 +66,21 @@ GRANT { { CREATE | USAGE } [,...] | ALL [ PRIVILEGES ] }
</para>
<para>
There is no need to grant privileges to the owner of an object (usually the user that created it),
as the owner has all privileges by default. (The owner could,
however, choose to revoke some of his own privileges for safety.)
The right to drop an object, or to alter it in any way is
not described by a grantable right; it is inherent in the owner,
and cannot be granted or revoked.
If <literal>WITH GRANT OPTION</literal> is specified, the recipient
of the privilege may in turn grant it to others. By default this
is not allowed. Grant options can only be granted to individual
users, not to groups or <literal>PUBLIC</literal>.
</para>
<para>
If <literal>WITH GRANT OPTION</literal> is specified, the recipient
of the privilege may in turn grant it to others. By default this
is not possible. Grant options can only be granted to individual
users, not groups or <literal>PUBLIC</literal>.
There is no need to grant privileges to the owner of an object
(usually the user that created it),
as the owner has all privileges by default. (The owner could,
however, choose to revoke some of his own privileges for safety.)
The right to drop an object, or to alter its definition in any way is
not described by a grantable privilege; it is inherent in the owner,
and cannot be granted or revoked. It is not possible for the owner's
grant options to be revoked, either.
</para>
<para>
@@ -263,6 +265,13 @@ GRANT { { CREATE | USAGE } [,...] | ALL [ PRIVILEGES ] }
except when absolutely necessary.
</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
owner of the affected object. In particular, privileges granted via
such a command will appear to have been granted by the object owner.
</para>
<para>
Currently, to grant privileges in <productname>PostgreSQL</productname>
to only a few columns, you must