Re: SET SESSION AUTHORIZATION (was Re: Real/effective user) - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: SET SESSION AUTHORIZATION (was Re: Real/effective user)
Date
Msg-id Pine.LNX.4.30.0104232306590.758-100000@peter.localdomain
Whole thread Raw
In response to Re: SET SESSION AUTHORIZATION (was Re: Real/effective user)  (Karel Zak <zakkr@zf.jcu.cz>)
List pgsql-hackers
Karel Zak writes:

>  Great! With this feature is possible use persisten connection and
> on-the-fly changing actual user, right? It's very useful for example
> web application that checking user privilege via SQL layout.

A real persistent connection solution would require real session
management, especially the ability to reset configuration options made
during the previous session.

> (connected as superuser)
>
>  set session authorization 'userA';
>  set session authorization 'userB';
>
> IMHO it must be disable, right must be something like:
>
>  set session authorization 'userA';
>  unset session authorization;        <-- switch back to superuser
>  set session authorization 'userB';

You can't "unset" the session user, there must always be one because there
is nothing below it.

> ..like as on Linux:
>
> # su - zakkr
> $ id -u
> 1000
> $ su - jmarek
> Password:
> su: Authentication failure
> Sorry.

The difference here is that 'su' also starts a new session but set session
authorization changes the state of the current session.  So 'su' is
similar to

START SESSION;  -- Don't know if this is the syntax.
SET SESSION AUTHORIZATION 'xxx';

all in one command.  When and if we get real session management we will
probably have the ability to revert user identity changes like you
probably imagine.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter



pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: refusing connections based on load ...
Next
From: Tom Lane
Date:
Subject: Re: concurrent Postgres on NUMA - howto ?