Re: New Privilege model purposal

From: JanWieck(at)t-online(dot)de (Jan Wieck)
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New Privilege model purposal
Date: 2000-07-25 21:30:34
Message-ID: 200007252130.XAA21510@hot.jw.home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Brenner 2000-07-25 22:40:30 Re: Inprise InterBase(R) 6.0 Now Free and Open Source
Previous Message Jan Wieck 2000-07-25 20:49:50 Re: [GENERAL] Comment #line after pre-processing