Re: Real/effective user - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Real/effective user
Date
Msg-id 24988.987531338@sss.pgh.pa.us
Whole thread Raw
In response to Real/effective user  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Real/effective user  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Terminology note:  In SQL 'real user' == SESSION_USER, 'effective user' ==
> CURRENT_USER.

Not sure about that.  I suspect that we actually need three values:

1. "real user" = what you originally authenticated to the postmaster.

2. "session user" = what you can SET if your real identity is a superuser.

3. "current user" = effective userid for permission checks.

current user is the value that would be pushed and popped during calls
to setuid functions.  The big reason for distinguishing current and
session user is that session user is what current user needs to revert to
after an elog.

Whether SQL's SESSION_USER corresponds to the first or second of these
concepts remains to be determined.

> This is nice, but the other end of the plan doesn't actually want to play
> along.  In clause 11.1 SR 2b) it is described that the owner of a new
> schema defaults to the *session* user.

I think we could still accept that, if we distinguish session and
current user as above.  (I have not yet read the spec to see if it
agrees though ;-))

Whether this is a good idea is another question; if a setuid function
does a CREATE, shouldn't the created object be owned by the setuid user?
I'm not sure that I *want* to accept the SQL spec on this point.
        regards, tom lane


pgsql-hackers by date:

Previous
From: ncm@zembu.com (Nathan Myers)
Date:
Subject: Re: Another news story in need of 'enlightenment'
Next
From: "Mikheev, Vadim"
Date:
Subject: RE: AW: AW: timeout on lock feature