From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: For review: Server instrumentation patch |
Date: | 2005-07-25 14:00:38 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE6C77C1@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Larry Rosenman | 2005-07-25 14:00:41 | Re: regression failure on latest CVS |
Previous Message | Tom Lane | 2005-07-25 13:54:38 | Re: For review: Server instrumentation patch |