Re: [PATCHES] Re: [PATCH] Re: Setuid functions
От | Peter Eisentraut |
---|---|
Тема | Re: [PATCHES] Re: [PATCH] Re: Setuid functions |
Дата | |
Msg-id | Pine.LNX.4.30.0107112330040.679-100000@peter.localdomain обсуждение исходный текст |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: