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

Mark Volpe writes:

> Good point. Would the issue be resolved by either:
>
> - Only allowing the database superuser to use this mechanism?

If you mean "only allow a superuser do define functions using this
mechanism", that could work. But it would probably make this feature a
lot less attractive, because any setuid function would have to run with
super powers.

> - Allowing it only in trigger functions? (That way a user has to actually own
> one of the tables)

Your premise is no longer correct in 7.2devel.

>
> 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
>
>

--
Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter