> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Monday, January 26, 2004 7:56 PM
> To: Bruce Momjian
> Cc: eepstein@prajnait.com; PostgreSQL-development
> Subject: Re: [HACKERS] Extending SET SESSION AUTHORIZATION
>
>
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Ezra Epstein wrote:
> >> I'd like to extend SET SESSION AUTHORIZATION to support a form
> which takes a
> >> password.
>
> > Uh, a password? What purpose would that serve?
>
> Indeed. SET SESSION AUTH is already allowed only to superusers --- a
> superuser hardly needs any additional privileges to become whoever he
> wants.
>
> regards, tom lane
>
For exactly the opposite usage: allowing a non-privileged user to take on a
different authorization IFF a password is also supplied. This allows a user
to use an existing connection (so, for example, connection pooling works)
and not require a high priv'd account to then act as a specific (and
specifically priv'd) user of the system.
E.g., I could then have a user who has only connection privs for the DB and
then use a SET SESSION AUTH as a means of "logging in" as a specific user.
What this buys me: Connection pooling (critical for volume web apps) Postgres (DB) level enforcement of
privilegesvia GRANT and REVOKE : so
that my priv scheme is consistent across db access methods and I don't have
to be too concerned about replicating the authorization logic out in the app
layer.
== Ezra Epstein.