On 09/29/2012 01:16:51 AM, Karl O. Pinc wrote:
> The attached documentation patch further describes the
> additive nature of the permission system.
Attached a second patch, applied after the
first, to extend the discussion
further regards roles.
(Original patch attached for reference.)
Karl <k...@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index fb81af4..73f88e0 100644
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
@@ -429,11 +429,27 @@ GRANT <replaceable class="PARAMETER">role_name</replaceable> [, ...] TO <replace
</para>
<para>
- A user may perform <command>SELECT</>, <command>INSERT</>, etc. on a
- column if he holds that privilege for either the specific column or
- its whole table. Granting the privilege at the table level and then
- revoking it for one column will not do what you might wish: the
- table-level grant is unaffected by a column-level operation.
+ Permission granted at any level of the
+ <database>database</><literal>.</><database>schema</><literal>.</><database>table</><literal>.</><database>column</>
+ object hierarchy grants permission to all contained objects.
+ E.g. a user may perform <command>SELECT</>, <command>INSERT</>,
+ etc. on a column if he holds that privilege for either the
+ specific column or its whole table. Granting the privilege at the
+ table level and then revoking it for one column will not do what
+ you might wish: the table-level grant is unaffected by a
+ column-level operation. Granting a privilege to some columns of a
+ table and denying the privilege to the table's other columns is
+ done in the same way as regards all other hierarchically organized
+ database objects (e.g. granting a privilege to some tables in a
+ schema and denying the privilege to the schema's other tables):
+ deny privilege to the protected columns, to their table, their
+ schema, and their database; grant privilege to the permitted
+ columns. As <link
+ linkend="sql-grant-description-objects">described above</link>,
+ permissions granted to the roles assigned a user are likewise
+ entirely additive. Permissions throughout
+ <productname>PostgreSQL</productname> combine in this uniform
+ fashion.
</para>
<para>
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index 73f88e0..0e878ba 100644
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
@@ -453,6 +453,22 @@ GRANT <replaceable class="PARAMETER">role_name</replaceable> [, ...] TO <replace
</para>
<para>
+ Further, roles having the <literal>INHERIT</literal> attribute
+ that are assigned to other roles in a hierarchical fashion are
+ additive of permission in the fashion of the
+ <database>database</><literal>.</><database>schema</><literal>.</><database>table</><literal>.</><database>column</>
+ hierarchy. E.g. a user's login role can be assigned a role of
+ <literal>accountant</> which is in turn assigned a role of
+ <literal>employee</>. The user would have the permissions of an
+ <literal>accountant</> and, be virtue of the role hierarchy, also
+ all permissions granted to <literal>employee</>s. Unlike the
+ fixed
+ <database>database</><literal>.</><database>schema</><literal>.</><database>table</><literal>.</><database>column</>
+ hierarchy the <productname>PostgreSQL</> user is free to fashion
+ roles into arbitrary hierarchical structures.
+ </para>
+
+ <para>
When a non-owner of an object attempts to <command>GRANT</> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
