> -----Original Message-----
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 26, 2004 7:56 PM
> To: Bruce Momjian
> Cc: [EMAIL PROTECTED]; PostgreSQL-development
> Subject: Re: [HACKERS] Extending SET SESSION AUTHORIZATION
>
>
> Bruce Momjian <[EMAIL PROTECTED]> 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.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
