Re: [PATCHES] Re: [PATCH] Re: Setuid functions

From: Mark Volpe <volpe(dot)mark(at)epa(dot)gov>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Mark Volpe <volpe(dot)mark(at)epamail(dot)epa(dot)gov>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] Re: [PATCH] Re: Setuid functions
Date: 2001-07-11 22:06:56
Message-ID: 3B4CCE00.D9B60127@epa.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Good point. Would the issue be resolved by either:

- Only allowing the database superuser to use this mechanism?
- Allowing it only in trigger functions? (That way a user has to actually own
one of the tables)

Mark

Peter Eisentraut wrote:
>
> Bruce Momjian writes:
>
> > > Peter might be referring to this:
> > >
> > > http://fts.postgresql.org/db/mw/msg.html?mid=1022775
> > >
> > > There was some discussion afterward, but I don't think a definite conclusion
> > > was reached.
> >
> > But I see Tom Lane saying he doesn't see a security issue:
> >
> > http://fts.postgresql.org/db/mw/msg.html?mid=1022758
> >
> > I don't pretend to understand it. Just tell me what to do with the
> > patch. :-)
>
> The problem with setuid functions in general is that a database user can
> effectively re-grant privileges to which he has no grant privileges.
> E.g.,
>
> user1=> create table table1 (id int, secret_content text);
> user1=> grant select on test to user2;
>
> /* made up the syntax */
> user2=> create function testfunc (int) returns text as '
> user2'> begin
> user2'> set authorization definer;
> user2'> return select secret_content from table1 where id = $1;
> user2'> end;' as 'plpgsql';
>
> user3=> select * from table1 where id = 5;
> (fails)
> user3=> select testfunc(5);
> (succeeds)
>
> Tom has a point that as soon as user2 has the select privilege, he can
> make a private copy of table1 and send it to user3.
>
> But if you take this attitude you might as well get rid of the
> fine-grained privilege system, you'd just need 'select to public'. Also,
> there may be other security or at least auditing mechanisms to supervise
> the communication between user2 and user3. Or maybe user2 and user3 are
> just pseudo-users implementing some sort of "least privilege" paranoid
> design.
>
> At least we should discuss whether we'd eventually like to have grantable
> privileges, and if so, how this would fit in.
>
> --
> Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-07-11 22:19:31 Re: [PATCH] Patch to make pg_hba.conf handle virtualhost access control and samehost keyword
Previous Message Mark 2001-07-11 21:55:08 Re: vacuum problems

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2001-07-11 22:14:27 Re: encode in base code
Previous Message Peter Eisentraut 2001-07-11 21:53:28 Re: [PATCHES] Re: [PATCH] Re: Setuid functions