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@gmx.net http://funkturm.homeip.net/~peter
