Re: "setuid" functions, a solution to the RI privilege problem
От | Peter Eisentraut |
---|---|
Тема | Re: "setuid" functions, a solution to the RI privilege problem |
Дата | |
Msg-id | Pine.LNX.4.21.0009090153310.345-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: "setuid" functions, a solution to the RI privilege problem ("Ross J. Reedstrom" <reedstrm@rice.edu>) |
Список | pgsql-hackers |
Ross J. Reedstrom writes: > This sounds good. The sad part of this story is that, while setuid functions work well for me in my tree, they cannot be used for the RI problem after all. The problem is that the lookup table for builtin function is already generated at compile time (Gen_fmgrtab.sh), whereas we don't know the user id of their owner until initdb at the earliest. Hence setuid functions don't work for builtins, currently. (With 7.2 I plan to get rid of pg_shadow.usesysid and identify users via pg_shadow.oid and the superuser oid will be hard-coded into include/catalog/pg_shadow.h, so at that point they will work.) An alternative answer would be to tie the user id not to the owner of the function but to the owner of the trigger, as an additional feature. > Good for functions. Rather than a boolean, how about something to store > the three standard defined behaviors DEFINER,INVOKER,IMPLEMENTATION > DEFINED: "proauth" int, with #DEFINES, perhaps? Or, we could store > the userid that this procedure will run as, with null signifying > invoker. Well, the standards defines these three behaviours, in terms of its "authorization stack": * INVOKER -- nothing changes when the function is called * DEFINER -- push function owner's identifier on top of stack * IMPLEMENTATION DEFINED -- put whatever you want on the stack Since IMPLEMENTATION DEFINED is the default it has to be what we have now, which in turn is INVOKER. So ISTM that we do not have 3 options really. > (BTW, that's the first time I've seen 'IMPLEMENTATION DEFINED' > in a standard leaking out into the defined grammar!) I have a sneaking suspicion that this was done because certain vendors with large interests in the SQL specification process had completely incompatible behaviours by default that would not fit in with the SQL model at all, so they could only be described by "do what you want". ;-) > I have some concerns about views, see below. No clue about views... :-\ -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: