Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Before discussing "limitations" you should first justify why we need any
>> such concept at all. It was no part of the original TODO item and I
>> cannot see any good use for it.
> There are permissions which are not grantable but exist as implicitly
> granted to the owner of object. These include drop, truncate, alter.
> Practically, I find myself having to change the owner of objects which I
> create almost as often as I'm defining the ACL for those objects. In
> many of our schemas all the objects should be owned by the same 'admin'
> role so that those who are in that role can perform the actions which
> are only available to object owners, much the same as those objects
> having a certain set of minimum ACLs.
I don't see any argument here for not creating the object as owned by
the creator -- as you note, SET ROLE is the way to cause something to be
owned by a role you have permission to become. The important difference
is that SET ROLE actually checks that you have that permission, whereas
a magical catalog entry saying "create objects as somebody else instead"
wouldn't. Maybe you could make it do so, but that would just be a
surprising behavior IMHO; and surprising security-related behaviors are
seldom a good idea.
BTW, I believe a schema owner can DROP any contained object whether he
owns it or not; without that the owner's ability to DROP the schema
would of course be worthless...
> I had thought it was going to be possible to set up roles/permissions
> such that a newly created object would be owned by the role through
> which the CREATE permission is given but that doesn't seem to be the
> case (or perhaps I'm doing something wrong with it).
Hm, I have some vague recollection that we considered that and rejected
it. Probably because it's ill-defined: what if there is more than one
path through which you've been granted CREATE permission?
regards, tom lane