Skip site navigation (1) Skip section navigation (2)

Re: Extending SET SESSION AUTHORIZATION

From: "Ezra Epstein" <eepstein(at)prajnait(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extending SET SESSION AUTHORIZATION
Date: 2004-01-27 06:00:17
Message-ID: GJEMKNGMHLIGIBLPFHCPGEOPCCAA.eepstein@prajnait.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> -----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.



In response to

Responses

pgsql-hackers by date

Next:From: Shridhar DaithankarDate: 2004-01-27 07:10:51
Subject: Re: Extending SET SESSION AUTHORIZATION
Previous:From: Bruce MomjianDate: 2004-01-27 04:01:43
Subject: Re: [HACKERS] What's left?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group