[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-hackers
Subject:    Re: [HACKERS] Doc patch, further describe and-mask nature of the permission system
From:       "Karl O. Pinc" <kop () meme ! com>
Date:       2012-09-29 7:28:40
Message-ID: 1348903720.22269.1 () mofo
[Download RAW message or body]

On 09/29/2012 01:16:51 AM, Karl O. Pinc wrote:

> The attached documentation patch further describes the=20
> 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 <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein


["grants-are-additive.patch" (text/x-patch)]

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>


["grants-of-roles-are-additive.patch" (text/x-patch)]

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


[prev in list] [next in list] [prev in thread] [next in thread]