Re: [PATCHES] Re: [PATCH] Re: Setuid functions
От | Peter Eisentraut |
---|---|
Тема | Re: [PATCHES] Re: [PATCH] Re: Setuid functions |
Дата | |
Msg-id | Pine.LNX.4.30.0107121648050.681-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: [PATCHES] Re: [PATCH] Re: Setuid functions (Mark Volpe <volpe.mark@epa.gov>) |
Ответы |
Re: [PATCHES] Re: [PATCH] Re: Setuid functions
|
Список | pgsql-hackers |
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@gmx.net http://funkturm.homeip.net/~peter > > -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
В списке pgsql-hackers по дате отправления: