Re: [PATCHES] Users/Groups -> Roles

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > That needs a check for superuser though because while the test will pass
> > on the 'pg_class_ownercheck' side, it won't on the 'is_role_member' side
>
> Um, right, that was another problem I had with it --- at one point the
> regression tests were failing because the superuser wasn't allowed to
> reassign object ownership ...

Yeah, sorry about that.

> I'm still fairly concerned about the security implications of letting
> ordinary users reassign object ownership. The fact that SET ROLE would
> let you *create* an object with ownership X is a long way away from
> saying that you should be allowed to change an *existing* object to have
> ownership X. This is particularly so if you are a member of a couple of
> different roles with different memberships: you will be able to cause
> objects to become effectively owned by certain other people, or make
> them stop being effectively owned by those people. I don't have a clear
> trouble case in mind at the moment, but this sure sounds like the stuff
> of routine security-hole reports. (Altering the ownership of a SECURITY
> DEFINER function, in particular, sounds like a great path for a cracker
> to pursue.)

SET ROLE also lets you *drop* an object owned by that role. Or alter
it. Or CREATE OR REPLACE FUNCTION ...

I can understand your concern. The specific use case I'm thinking about
is where a user creates an object, does some work on it, and then wants
to change its ownership to be owned by a role which that user is in. I
find myself doing that a fair bit (as superuser atm). One thing I don't
like about limiting it to that is that you then can't go back without
the whole drop/create business or getting an admin.

This also isn't stuff that couldn't be done through other means, even in
the SECURITY DEFINER function case, you just need to drop, set role,
create. Having a role with members be able to own objects isn't meant
to replace the privileges system and I don't expect people to try to use
it to.

I can perhaps see a special case for SECURITY DEFINER functions but if
we're going to special case them I'd think we'd need to make them only
be creatable/modifiable at all by superusers or add another flag to the
role to allow that.

Thanks,

Stephen