From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Real/effective user |
Date: | 2001-04-17 18:15:38 |
Message-ID: | 24988.987531338@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyle VanderBeek | 2001-04-17 18:29:27 | Re: Large Object problems (was Re: JDBC int8 hack) |
Previous Message | Nathan Myers | 2001-04-17 18:13:01 | Re: Another news story in need of 'enlightenment' |