Re: [PATCHES] Roles - SET ROLE Updated

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [PATCHES] Roles - SET ROLE Updated
Дата
Msg-id 20050721211011.GI24207@ns.snowman.net
обсуждение исходный текст
Ответ на Re: [PATCHES] Roles - SET ROLE Updated  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCHES] Roles - SET ROLE Updated  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > Perhaps the specification isn't but I'm pretty sure other
> > implementations follow the SET ROLE -> current authorization
> > identifier (and thus dropping other rights granted to the CURRENT_USER).
>
> My current reading of 4.31 is that SET ROLE *doesn't* drop rights, which
> means we need to rethink all of this.  However, on this point:

Yeah, it seems to add them.  Honestly, my recollection from working on
Oracle is that you have access to all the roles you've been granted when
you connect as a user.  If it'd be useful I'd be happy to see about
finding out exactly what Oracle does in this regard and if it actually
follows the specification or what.

> > It's in 4.34.1.1, at least in the SQL2003 specification, and it reads:
> > "This stack is maintained using a "last-in, first-out" discipline, and
> > effectively only the top cell is visible.
>
> Yes, but the only events that push or pop stack entries are entry/exit
> of an external procedure (think SECURITY DEFINER procedure).  SET ROLE
> doesn't push or pop anything, it just alters the current top entry.
> (Which must in fact be the *only* entry, given that SET ROLE is only
> allowed at outer level...)

Alright, that would make the later language make more sense.
Thanks,
    Stephen

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: [PATCHES] Roles - SET ROLE Updated
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCHES] Roles - SET ROLE Updated