Re: Extending SET SESSION AUTHORIZATION

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Monday, January 26, 2004 7:56 PM
> To: Bruce Momjian
> Cc: eepstein(at)prajnait(dot)com; PostgreSQL-development
> Subject: Re: [HACKERS] Extending SET SESSION AUTHORIZATION
>
>
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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 privileges via 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.