Peter Eisentraut wrote:
> Hmm, I thunk I was working on that. I put out a proposal on May 22, and we
> came to a pretty good understanding about the details and I was working on
> a new specification.
I apologize. Karel already told me so and it seems I missed that discussion somehow.
Anyway, it's good to hear you're still on it. What's the estimated time you think it'll be ready to get
patchedin?
> > The system will manage a stack, remembering nested
> > states of the effective user id. Calls through the
> > function manager can switch for- and backward to
> > another one, so prosetuid functions will inherit the
> > effective permissions of the function (trigger)
> > owner. The stack is reinitialized at transaction
> > aborts.
>
> This is definitely necessary, but it needs to be more general. There is a
> command SET SESSION AUTHORIZATION, which is essentially `su', that could
> make use of this also.
I see - a session level userid switch. Should this one affect the setting of realuid as well or not? And
must it be possible from inside a function (or whatever) and then get rolled back if the function returns?
Shouldit stay permanent otherwise if issued from inside a function?
The thing users actually complain about is the requirement of UPDATE permissions to REFERENCE a table. This could
be fixed with making RI triggers setuid functions for 7.1 and check that the user at least has SELECT
permission on the referenced table during constraint creation. This would also remove the actual DOS problem,
thata user could potentiall create a referencing table and not giving anyone who can update the referenced
oneupdate permissions on it too.
I think it's worth doing it now, and couple it later with your general access control things.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
