Thread: Role membership and DROP
I realized only today that if role A is a member of role B, A can ALTER and DROP objects owned by B. I don't have a problem with that, but the documentation seems to suggest otherwise. For example, for DROP TABLE: Only the table owner, the schema owner, and superuser can drop a table. Should I compose a doc patch, or is that too much of a corner case to mention? I wanted to ask before I do the repetetive work. Yours, Laurenz Albe
Laurenz Albe <laurenz.albe@cybertec.at> writes: > I realized only today that if role A is a member of role B, > A can ALTER and DROP objects owned by B. > I don't have a problem with that, but the documentation seems to > suggest otherwise. For example, for DROP TABLE: > Only the table owner, the schema owner, and superuser can drop a table. Generally, if you are a member of a role, that means you are the role for privilege-test purposes. I'm not on board with adding "(or a member of that role)" to every place it could conceivably be added; I think that would be more annoying than helpful. It might be worth clarifying this point in section 5.7, https://www.postgresql.org/docs/devel/ddl-priv.html but let's not duplicate that in every ref/ page. regards, tom lane
On Wed, 2019-11-13 at 17:17 -0500, Tom Lane wrote: > Laurenz Albe <laurenz.albe@cybertec.at> writes: > > I realized only today that if role A is a member of role B, > > A can ALTER and DROP objects owned by B. > > I don't have a problem with that, but the documentation seems to > > suggest otherwise. For example, for DROP TABLE: > > Only the table owner, the schema owner, and superuser can drop a table. > > Generally, if you are a member of a role, that means you are the role for > privilege-test purposes. I'm not on board with adding "(or a member of > that role)" to every place it could conceivably be added; I think that > would be more annoying than helpful. > > It might be worth clarifying this point in section 5.7, > > https://www.postgresql.org/docs/devel/ddl-priv.html > > but let's not duplicate that in every ref/ page. That's much better. I have attached a proposed patch. Yours, Laurenz Albe
Attachment
On Wed, 2019-11-13 at 17:17 -0500, Tom Lane wrote: > Laurenz Albe <laurenz.albe@cybertec.at> writes: > > I realized only today that if role A is a member of role B, > > A can ALTER and DROP objects owned by B. > > I don't have a problem with that, but the documentation seems to > > suggest otherwise. For example, for DROP TABLE: > > Only the table owner, the schema owner, and superuser can drop a table. > > Generally, if you are a member of a role, that means you are the role for > privilege-test purposes. I'm not on board with adding "(or a member of > that role)" to every place it could conceivably be added; I think that > would be more annoying than helpful. > > It might be worth clarifying this point in section 5.7, > > https://www.postgresql.org/docs/devel/ddl-priv.html > > but let's not duplicate that in every ref/ page. That's much better. I have attached a proposed patch. Yours, Laurenz Albe
Laurenz Albe <laurenz.albe@cybertec.at> writes: > On Wed, 2019-11-13 at 17:17 -0500, Tom Lane wrote: >> It might be worth clarifying this point in section 5.7, >> https://www.postgresql.org/docs/devel/ddl-priv.html >> but let's not duplicate that in every ref/ page. > I have attached a proposed patch. <para> The right to modify or destroy an object is always the privilege of - the owner only. + the owner. Like all privileges, that right can be inherited by members of + the owning role. </para> Hm. This is more or less contradicting the original meaning of the existing sentence, so maybe we need to rewrite a bit more. What do you think of The right to modify or destroy an object is inherent in being the object's owner. Like all privileges, that right can be inherited by members of the owning role; but there is no way to grant or revoke it more selectively. A larger problem (pre-existing, since there's a reference to being a member of the owning role just a bit further down) is that I don't think we've defined role membership at this point, so the reader is quite entitled to come away more confused than they were before. It might not be advisable to try to cover role membership here, but we should at least add a cross-reference to where it's explained. regards, tom lane
Laurenz Albe <laurenz.albe@cybertec.at> writes: > On Wed, 2019-11-13 at 17:17 -0500, Tom Lane wrote: >> It might be worth clarifying this point in section 5.7, >> https://www.postgresql.org/docs/devel/ddl-priv.html >> but let's not duplicate that in every ref/ page. > I have attached a proposed patch. <para> The right to modify or destroy an object is always the privilege of - the owner only. + the owner. Like all privileges, that right can be inherited by members of + the owning role. </para> Hm. This is more or less contradicting the original meaning of the existing sentence, so maybe we need to rewrite a bit more. What do you think of The right to modify or destroy an object is inherent in being the object's owner. Like all privileges, that right can be inherited by members of the owning role; but there is no way to grant or revoke it more selectively. A larger problem (pre-existing, since there's a reference to being a member of the owning role just a bit further down) is that I don't think we've defined role membership at this point, so the reader is quite entitled to come away more confused than they were before. It might not be advisable to try to cover role membership here, but we should at least add a cross-reference to where it's explained. regards, tom lane
On Fri, 2019-11-15 at 13:41 -0500, Tom Lane wrote: > Laurenz Albe <laurenz.albe@cybertec.at> writes: > > On Wed, 2019-11-13 at 17:17 -0500, Tom Lane wrote: > > > It might be worth clarifying this point in section 5.7, > > > https://www.postgresql.org/docs/devel/ddl-priv.html > > > but let's not duplicate that in every ref/ page. > > I have attached a proposed patch. > > <para> > The right to modify or destroy an object is always the privilege of > - the owner only. > + the owner. Like all privileges, that right can be inherited by members of > + the owning role. > </para> > > Hm. This is more or less contradicting the original meaning of the > existing sentence, so maybe we need to rewrite a bit more. What do > you think of > > The right to modify or destroy an object is inherent in being the > object's owner. Like all privileges, that right can be inherited by > members of the owning role; but there is no way to grant or revoke > it more selectively. > > A larger problem (pre-existing, since there's a reference to being a > member of the owning role just a bit further down) is that I don't think > we've defined role membership at this point, so the reader is quite > entitled to come away more confused than they were before. It might not > be advisable to try to cover role membership here, but we should at > least add a cross-reference to where it's explained. I think you are right about the potential confusion; I have added a cross-reference. That cross-reference is hopefully still in short-term memory when the reader proceeds to the second reference to role membership a few sentences later. I like your second sentence, but I think that "the right ... is inherent in being the ... owner" is unnecessarily complicated. Removing the "always" and "only" makes the apparent contradiction between the sentences less jarring to me. I won't fight about words though. Attached is my second attempt. Yours, Laurenz Albe
On Fri, 2019-11-15 at 13:41 -0500, Tom Lane wrote: > Laurenz Albe <laurenz.albe@cybertec.at> writes: > > On Wed, 2019-11-13 at 17:17 -0500, Tom Lane wrote: > > > It might be worth clarifying this point in section 5.7, > > > https://www.postgresql.org/docs/devel/ddl-priv.html > > > but let's not duplicate that in every ref/ page. > > I have attached a proposed patch. > > <para> > The right to modify or destroy an object is always the privilege of > - the owner only. > + the owner. Like all privileges, that right can be inherited by members of > + the owning role. > </para> > > Hm. This is more or less contradicting the original meaning of the > existing sentence, so maybe we need to rewrite a bit more. What do > you think of > > The right to modify or destroy an object is inherent in being the > object's owner. Like all privileges, that right can be inherited by > members of the owning role; but there is no way to grant or revoke > it more selectively. > > A larger problem (pre-existing, since there's a reference to being a > member of the owning role just a bit further down) is that I don't think > we've defined role membership at this point, so the reader is quite > entitled to come away more confused than they were before. It might not > be advisable to try to cover role membership here, but we should at > least add a cross-reference to where it's explained. I think you are right about the potential confusion; I have added a cross-reference. That cross-reference is hopefully still in short-term memory when the reader proceeds to the second reference to role membership a few sentences later. I like your second sentence, but I think that "the right ... is inherent in being the ... owner" is unnecessarily complicated. Removing the "always" and "only" makes the apparent contradiction between the sentences less jarring to me. I won't fight about words though. Attached is my second attempt. Yours, Laurenz Albe
Attachment
Laurenz Albe <laurenz.albe@cybertec.at> writes: > On Fri, 2019-11-15 at 13:41 -0500, Tom Lane wrote: >> Laurenz Albe <laurenz.albe@cybertec.at> writes: >>> On Wed, 2019-11-13 at 17:17 -0500, Tom Lane wrote: >>>> It might be worth clarifying this point in section 5.7, >>>> https://www.postgresql.org/docs/devel/ddl-priv.html > I like your second sentence, but I think that "the right ... is inherent > in being the ... owner" is unnecessarily complicated. > Removing the "always" and "only" makes the apparent contradiction between > the sentences less jarring to me. I think it's important to emphasize that this is implicit in object ownership. Looking at the page again, I notice that there's a para a little further down that overlaps quite a bit with what we're discussing here, but it's about implicit grant options rather than the right to DROP. In the attached, I reworded that too, and moved it because it's not fully intelligible until we've explained grant options. Thoughts? regards, tom lane diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 9d6ec2c..0be0774 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -1578,8 +1578,10 @@ ALTER TABLE products RENAME TO items; </para> <para> - The right to modify or destroy an object is always the privilege of - the owner only. + The right to modify or destroy an object is inherent in being the + object's owner, and cannot be granted or revoked in itself. + (However, like all privileges, that right can be inherited by + members of the owning role; see <xref linkend="role-membership"/>.) </para> <para> @@ -1614,17 +1616,11 @@ GRANT UPDATE ON accounts TO joe; </para> <para> - To revoke a privilege, use the fittingly named + To revoke a previously-granted privilege, use the fittingly named <xref linkend="sql-revoke"/> command: <programlisting> REVOKE ALL ON accounts FROM PUBLIC; </programlisting> - The special privileges of the object owner (i.e., the right to do - <command>DROP</command>, <command>GRANT</command>, <command>REVOKE</command>, etc.) - are always implicit in being the owner, - and cannot be granted or revoked. But the object owner can choose - to revoke their own ordinary privileges, for example to make a - table read-only for themselves as well as others. </para> <para> @@ -1639,6 +1635,13 @@ REVOKE ALL ON accounts FROM PUBLIC; </para> <para> + An object's owner can choose to revoke their own ordinary privileges, + for example to make a table read-only for themselves as well as others. + But owners are always treated as holding all grant options, so they + can always re-grant their own privileges. + </para> + + <para> The available privileges are: <variablelist>
Laurenz Albe <laurenz.albe@cybertec.at> writes: > On Fri, 2019-11-15 at 13:41 -0500, Tom Lane wrote: >> Laurenz Albe <laurenz.albe@cybertec.at> writes: >>> On Wed, 2019-11-13 at 17:17 -0500, Tom Lane wrote: >>>> It might be worth clarifying this point in section 5.7, >>>> https://www.postgresql.org/docs/devel/ddl-priv.html > I like your second sentence, but I think that "the right ... is inherent > in being the ... owner" is unnecessarily complicated. > Removing the "always" and "only" makes the apparent contradiction between > the sentences less jarring to me. I think it's important to emphasize that this is implicit in object ownership. Looking at the page again, I notice that there's a para a little further down that overlaps quite a bit with what we're discussing here, but it's about implicit grant options rather than the right to DROP. In the attached, I reworded that too, and moved it because it's not fully intelligible until we've explained grant options. Thoughts? regards, tom lane diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 9d6ec2c..0be0774 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -1578,8 +1578,10 @@ ALTER TABLE products RENAME TO items; </para> <para> - The right to modify or destroy an object is always the privilege of - the owner only. + The right to modify or destroy an object is inherent in being the + object's owner, and cannot be granted or revoked in itself. + (However, like all privileges, that right can be inherited by + members of the owning role; see <xref linkend="role-membership"/>.) </para> <para> @@ -1614,17 +1616,11 @@ GRANT UPDATE ON accounts TO joe; </para> <para> - To revoke a privilege, use the fittingly named + To revoke a previously-granted privilege, use the fittingly named <xref linkend="sql-revoke"/> command: <programlisting> REVOKE ALL ON accounts FROM PUBLIC; </programlisting> - The special privileges of the object owner (i.e., the right to do - <command>DROP</command>, <command>GRANT</command>, <command>REVOKE</command>, etc.) - are always implicit in being the owner, - and cannot be granted or revoked. But the object owner can choose - to revoke their own ordinary privileges, for example to make a - table read-only for themselves as well as others. </para> <para> @@ -1639,6 +1635,13 @@ REVOKE ALL ON accounts FROM PUBLIC; </para> <para> + An object's owner can choose to revoke their own ordinary privileges, + for example to make a table read-only for themselves as well as others. + But owners are always treated as holding all grant options, so they + can always re-grant their own privileges. + </para> + + <para> The available privileges are: <variablelist>
On Tue, 2019-11-19 at 13:21 -0500, Tom Lane wrote: > Laurenz Albe <laurenz.albe@cybertec.at> writes: > > On Fri, 2019-11-15 at 13:41 -0500, Tom Lane wrote: > > > Laurenz Albe <laurenz.albe@cybertec.at> writes: > > > > On Wed, 2019-11-13 at 17:17 -0500, Tom Lane wrote: > > > > > It might be worth clarifying this point in section 5.7, > > > > > https://www.postgresql.org/docs/devel/ddl-priv.html > > I like your second sentence, but I think that "the right ... is inherent > > in being the ... owner" is unnecessarily complicated. > > Removing the "always" and "only" makes the apparent contradiction between > > the sentences less jarring to me. > > I think it's important to emphasize that this is implicit in object > ownership. > > Looking at the page again, I notice that there's a para a little further > down that overlaps quite a bit with what we're discussing here, but it's > about implicit grant options rather than the right to DROP. In the > attached, I reworded that too, and moved it because it's not fully > intelligible until we've explained grant options. Thoughts? I am fine with that. Yours, Laurenz Albe
On Tue, 2019-11-19 at 13:21 -0500, Tom Lane wrote: > Laurenz Albe <laurenz.albe@cybertec.at> writes: > > On Fri, 2019-11-15 at 13:41 -0500, Tom Lane wrote: > > > Laurenz Albe <laurenz.albe@cybertec.at> writes: > > > > On Wed, 2019-11-13 at 17:17 -0500, Tom Lane wrote: > > > > > It might be worth clarifying this point in section 5.7, > > > > > https://www.postgresql.org/docs/devel/ddl-priv.html > > I like your second sentence, but I think that "the right ... is inherent > > in being the ... owner" is unnecessarily complicated. > > Removing the "always" and "only" makes the apparent contradiction between > > the sentences less jarring to me. > > I think it's important to emphasize that this is implicit in object > ownership. > > Looking at the page again, I notice that there's a para a little further > down that overlaps quite a bit with what we're discussing here, but it's > about implicit grant options rather than the right to DROP. In the > attached, I reworded that too, and moved it because it's not fully > intelligible until we've explained grant options. Thoughts? I am fine with that. Yours, Laurenz Albe
Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Tue, 2019-11-19 at 13:21 -0500, Tom Lane wrote:
>> Looking at the page again, I notice that there's a para a little further
>> down that overlaps quite a bit with what we're discussing here, but it's
>> about implicit grant options rather than the right to DROP. In the
>> attached, I reworded that too, and moved it because it's not fully
>> intelligible until we've explained grant options. Thoughts?
> I am fine with that.
OK, pushed.
regards, tom lane
Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Tue, 2019-11-19 at 13:21 -0500, Tom Lane wrote:
>> Looking at the page again, I notice that there's a para a little further
>> down that overlaps quite a bit with what we're discussing here, but it's
>> about implicit grant options rather than the right to DROP. In the
>> attached, I reworded that too, and moved it because it's not fully
>> intelligible until we've explained grant options. Thoughts?
> I am fine with that.
OK, pushed.
regards, tom lane