Re: Real/effective user

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

In response to

Responses

Browse pgsql-hackers by date

  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'