Re: [PATCHES] Roles - SET ROLE Updated

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] Roles - SET ROLE Updated
Date: 2005-07-25 17:12:01
Message-ID: 5755.1122311521@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> The problem I have with the spec's way is that it creates a disconnect
>> between the privilege environment seen at the outer level and the
>> environment seen within SECURITY DEFINER functions

> Essentially the union behavior is what the spec seems to say- except
> that only one or the other is valid inside a SECURITY DEFINER, as I
> understand it. So, you make everything do the union, but when you go
> into a SECURITY DEFINER function you set the one-not-set to NULL and
> handle that correctly in the union.

My understanding of things is that per spec, a SECURITY DEFINER function
can be owned by either a user or a role, and so within the function
either CURRENT_USER or CURRENT_ROLE would return the owner and the other
would return NULL. Emulating this would require a hard distinction
between users and roles that is simply not there in our implementation,
which is why I think they should both return the owner.

> Right, I would expect it to drop privileges when rolinherit = true. The
> second issue is one reason I don't particularly care for locking it into
> the catalog- it means we're building the system in such a way as to be
> unable to support what Oracle (at least) does today. If we end up
> needing to support it later, or wanting to, perhaps because the spec
> follows Oracle's lead and adds SET ROLE ALL, then we've got alot that
> would need to be changed because things have become dependent on the
> catalog directly.

To some extent SET ROLE ALL can be emulated by ALTER USER ... INHERIT.
I'm of two minds about whether an unprivileged user should be allowed
to adjust his own rolinherit flag --- in most cases it seems pretty
harmless (and Oracle evidently thinks it is) --- but one could imagine
that the roles have been set up on the assumption that you can't get
more than one role's privileges at a time. INHERIT (or SET ROLE ALL)
would break that assumption, and perhaps allow people to do unwanted
stuff.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message ohp 2005-07-25 17:19:05 Re: regression failure on latest CVS
Previous Message Andreas Pflug 2005-07-25 17:02:07 Re: For review: Server instrumentation patch

Browse pgsql-patches by date

  From Date Subject
Next Message Petr Jelinek 2005-07-25 17:14:44 Re: per user/database connections limit again
Previous Message Stephen Frost 2005-07-25 16:58:58 Re: [PATCHES] Roles - SET ROLE Updated