On Tue, Mar 8, 2011 at 11:48 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> I thought there was nothing particularly unreasonable about Owen's >> suggestion: let users with the CREATEROLE attribute comment on any role. >> I don't think COMMENT added to CREATE ROLE would be a very nice fix >> (aside from being ugly, what if you want to change the comment later?). > >> It strikes me actually that letting members of the role comment on it >> is not an amazingly good idea. They are not owners of the role in any >> meaningful sense --- for instance, they can't drop it. It'd be more >> reasonable and consistent to say that only superusers and holders of >> CREATEROLE can do COMMENT ON ROLE. > > In particular, I suggest the attached patch (code-complete, but sans > documentation changes). The changes here bring COMMENT ON ROLE into > line with the permission requirements for other operations on roles > that require ownership-like permissions. This patch modifies > check_object_ownership, which means it affects three call sites at > present: > > COMMENT ON ROLE > > ALTER EXTENSION ADD/DROP (but the target object cannot be a role) > > SECURITY LABEL IS (also couldn't be a role, at the moment) > > The SECURITY LABEL case, even though it's presently unimplemented, > seems to me to be a darn good argument for redefining the notion > of "role ownership" like this. Who would want a mere member of some > group role to be able to set that role's security label? > > Comments, objections?
I think it's a good change, but we should make sure to release-note it properly, along with the change you made for PLs. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
