On Tue, Mar 8, 2011 at 11:48 PM, Tom Lane <tgl@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. =A0They are not owners of the role in any
>> meaningful sense --- for instance, they can't drop it. =A0It'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). =A0The changes here bring COMMENT ON ROLE into
> line with the permission requirements for other operations on roles
> that require ownership-like permissions. =A0This patch modifies
> check_object_ownership, which means it affects three call sites at
> present:
>
> =A0 =A0 =A0 =A0COMMENT ON ROLE
>
> =A0 =A0 =A0 =A0ALTER EXTENSION ADD/DROP (but the target object cannot be =
a role)
>
> =A0 =A0 =A0 =A0SECURITY 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. =A0Who 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.
--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company