Re: For review: Server instrumentation patch
От | Magnus Hagander |
---|---|
Тема | Re: For review: Server instrumentation patch |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE6C77C1@algol.sollentuna.se обсуждение исходный текст |
Ответ на | For review: Server instrumentation patch ("Dave Page" <dpage@vale-housing.co.uk>) |
Ответы |
Re: For review: Server instrumentation patch
|
Список | pgsql-hackers |
<snip good explanation. Thanks.> > > Let me suggest another nice way for a superuser to do > whatever he wants. > > How about "CREATE UNTRUSTED PROCEDURAL LANGUAGE"? If you have say > > pl/perl or pl/tcl on the system, you just create the > untrusted version > > and away you go - because they use the same .so. > > Yeah, I was thinking earlier about proposing that the trusted > and untrusted versions need to be distinct .so's, so that the > admin can physically remove the untrusted ones to prevent > this scenario. > But, again, the existence of security hole A is not > justification for introducing security hole B. > > > Instead of trying to pick on one feature, how about trying > something > > constructive instead? > > That'd be fine with me --- but we have to introduce that > *before* we add obvious new security risks, not after. So what do you think of the proposed GUC? Or what about a parameter to restrict both COPY and the utility functions to certain subdirs only? (BTW, I was under the impression that the admin functions were restricted to the pgdata directory already, but I could be wrong - I don't have the latest version of the patch around) //Magnus
В списке pgsql-hackers по дате отправления: