Doc patch, further describe and-mask nature of the permission system
Hi,
The attached documentation patch further describes the
additive nature of the permission system.
This patch makes some sweeping statements. It needs
review by someone who knows whats in all the corners.
(I'm sure this would happen anyway, but it seems worth
mentioning.)
Paragraph structure is:
Describe permission semantics. Provide example of a common
error (unchanged from pre-existing text.) Generalize from
the example's lesson and provide correct process. Show
the semantics apply uniformly throughout Postgres.
Regards,
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Attachments:
grants-are-additive.patchtext/x-patch; charset=us-ascii; name=grants-are-additive.patchDownload
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>
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 <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Attachments:
grants-of-roles-are-additive.patchtext/x-patch; charset=us-ascii; name=grants-of-roles-are-additive.patchDownload
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
grants-are-additive.patchtext/x-patch; charset=us-ascii; name=grants-are-additive.patchDownload
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>
On 09/29/2012 02:28:40 AM, Karl O. Pinc wrote:
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.
Found a typo in the second patch. Resending
the original first patch and a v2 of the second.
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Attachments:
grants-are-additive.patchtext/x-patch; charset=us-ascii; name=grants-are-additive.patchDownload
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_v2.patchtext/x-patch; charset=us-ascii; name=grants-of-roles-are-additive_v2.patchDownload
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, by 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
On Sat, 2012-09-29 at 01:16 -0500, Karl O. Pinc wrote:
This patch makes some sweeping statements.
Unfortunately, they are wrong. What you term the additive nature is
really only a special case in the relationship between table and column
privileges. Schema and database privileges are completely separate
things.
On 11/13/2012 08:50:55 PM, Peter Eisentraut wrote:
On Sat, 2012-09-29 at 01:16 -0500, Karl O. Pinc wrote:
This patch makes some sweeping statements.
Unfortunately, they are wrong.
I will see if anything can be salvaged.
Regards,
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
On 11/14/2012 02:35:54 PM, Karl O. Pinc wrote:
On 11/13/2012 08:50:55 PM, Peter Eisentraut wrote:
On Sat, 2012-09-29 at 01:16 -0500, Karl O. Pinc wrote:
This patch makes some sweeping statements.
Unfortunately, they are wrong.
I will see if anything can be salvaged.
Here's another try.
(I bundled changes to both paragraphs into a single
patch.)
grants-of-roles-are-additive_v3.patch
Regards,
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Attachments:
grants-of-roles-are-additive_v3.patchtext/x-patch; charset=us-ascii; name=grants-of-roles-are-additive_v3.patchDownload
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index fb81af4..b57000c 100644
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
@@ -429,11 +429,32 @@ 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
+ Permission granted to a table grants permission to all the columns
+ of a table, regardless of permissions granted to the table's
+ columns. Granting a 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.
+ table-level grant is unaffected by a column-level operation. But
+ revoking permission at the table level and granting it at the
+ column level does grant permission to the column.
+ </para>
+
+ <para>
+ Roles can be fashioned into a permission hierarchy. Roles having
+ the <literal>INHERIT</literal> attribute (the default) that are
+ assigned to other roles in a hierarchical fashion produce a
+ permission system which behaves in the fashion of the
+ <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 all the permissions of
+ an <literal>accountant</> regardless of whether these permissions
+ are revoked from the <literal>employee</literal> role. And, by
+ virtue of the <literal>employee</>/<literal>accountant</> role
+ hierarchy, <literal>accountant</>s also have all permissions
+ granted to <literal>employee</>s. Unlike the fixed
+ <database>table</><literal>.</><database>column</> hierarchy the
+ <productname>PostgreSQL</> user is free to fashion roles into
+ arbitrary hierarchical structures.
</para>
<para>
On Mon, 2012-12-10 at 20:48 -0600, Karl O. Pinc wrote:
On 11/14/2012 02:35:54 PM, Karl O. Pinc wrote:
On 11/13/2012 08:50:55 PM, Peter Eisentraut wrote:
On Sat, 2012-09-29 at 01:16 -0500, Karl O. Pinc wrote:
This patch makes some sweeping statements.
Unfortunately, they are wrong.
I will see if anything can be salvaged.
Here's another try.
(I bundled changes to both paragraphs into a single
patch.)grants-of-roles-are-additive_v3.patch
I don't get the point of this change, especially why you are trying to
liken the roles system to the object hierarchy, when they are clearly
different and unrelated.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/16/2012 12:56:22 AM, Peter Eisentraut wrote:
On Mon, 2012-12-10 at 20:48 -0600, Karl O. Pinc wrote:
On 11/14/2012 02:35:54 PM, Karl O. Pinc wrote:
On 11/13/2012 08:50:55 PM, Peter Eisentraut wrote:
On Sat, 2012-09-29 at 01:16 -0500, Karl O. Pinc wrote:
This patch makes some sweeping statements.
Unfortunately, they are wrong.
I will see if anything can be salvaged.
Here's another try.
(I bundled changes to both paragraphs into a single
patch.)grants-of-roles-are-additive_v3.patch
I don't get the point of this change, especially why you are trying
to
liken the roles system to the object hierarchy, when they are clearly
different and unrelated.
It seems to me the that the permission system follows the object system
hierarchy in those cases where different levels of the object
hierarchy may have identical permissions. The exceptions being
permissions like USAGE, which seems to be a convenient common lexical
token but mean (and need to mean) something entirely different
at each level of the object hierarchy. ALL is also confuses the
issue, since it means "all permissions which work at this level
of the object hierarchy" and not "all permissions" so, say,
granting ALL to a database says nothing about INSERT permission.
I'm (clearly) not steeped in the pg permission system, but it
does seem that where permissions are "shared" between levels
of the object hierarchy there is a consistency in the
resulting interaction when granting/revoking at different
levels of the object hierarchy. Perhaps this is ipso facto
(counterexamples being automatically designated as
"not shared" by nature of the premise :)
or perhaps more an artifact of my attention than the
result of any sort of design. Anyway, my intent is to point
out this consistency. Since the way in which interactions
between permissions set at different levels of the object
hierarchy is sometimes useful I go on to describe how to
replicate the behavior and apply it outside the object
hierarchy.
In any case I thought the elaboration would be helpful.
I had a few minutes and cooked it up. If you don't don't think
it should go in then reject it. As noted already in the
docs, permissions are different at different levels of the
object hierarchy, but similar enough to describe in one place.
I was hoping to provide a possible framework for thinking
about permission interactions between object hierarchy levels
where such occur. Without any sort of framework everything
becomes a special case and it's hard to keep track of.
Thanks for spending time on it. If there's anything about
it that appeals then I will continue to work under
your direction.
Regards,
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers