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 patched in?
> > 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? Should it 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, that a user could potentiall
create a referencing table and not giving anyone who can
update the referenced one update 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(at)Yahoo(dot)com #