Re: [PATCHES] Roles - SET ROLE Updated

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:58:17
Message-ID: 20050725175817.GH24207@ns.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> 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.

I would have been more inclined to just pick one and always set it and
leave the other always null. For that, CURRENT_USER would be more
backwards-compatible, but for our implementation I'd tend to think
CURRENT_ROLE is more appropriate. That'd follow the spec closer and
would be closer to what functions written to the spec would expect.

I don't use SECURITY DEFINER functions much though so perhaps others
have a stronger opinion. I've been a bit suprised at the lack of
commentary from other people, perhaps they're just waiting to destroy
whatever we come up with once it's actually been implemented. :)

> To some extent SET ROLE ALL can be emulated by ALTER USER ... INHERIT.

Yeah, but that affects all sessions too, not just a single one, which
makes it quite a different thing.

> 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.

This is actually what I was thinking about when I was saying at some
point prior in this thread that we should have an option to indicate if
SET ROLE ALL is allowed or not. I don't think that users should be
allowed to adjust their own rolinherit flag. I think the default should
probably be 'true', even for users, but if an admin sets it to false
then I think that should be enforced and users shouldn't be allowed to
change it.

I suspect it's possible to disable 'SET ROLE ALL' in Oracle, and to turn
off having it done upon connection. I'd be somewhat suprised if it
wasn't possible but I havn't really investigated it either way. I don't
know if Oracle has a way to let you do it per-user/per-role though.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Wong 2005-07-25 18:35:21 Re: Checkpoint cost, looks like it is WAL/CRC
Previous Message Larry Rosenman 2005-07-25 17:47:01 Re: regression failure on latest CVS

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2005-07-25 17:59:10 Re: per user/database connections limit again
Previous Message Bruce Momjian 2005-07-25 17:17:44 Re: psql patch for displaying the username when asking password