Skip site navigation (1) Skip section navigation (2)

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 (view raw, whole thread or download thread mbox)
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.



# 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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group