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