Re: For review: Server instrumentation patch

"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
>> 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?

Well, it has more or less the same problem as the GUC in the
COPY-only-to-given-places proposal, which is that GUCs were never
intended to prevent superusers from changing their values. Right now
a remote superuser can't change a postmaster-start-time-only GUC, but
if we ever introduce a real remote admin facility I'd expect it to
support that, so it seems like a GUC intended not to be changeable by
superusers would have to be its own special category. I'd be inclined
not to expose it as a GUC at all, but make it some other mechanism
(maybe a postmaster command-line switch only?)

> 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)

We've gone back and forth on that with respect to the proposed admin
functions, and I forget which way the current patch is. But it doesn't
do much to stop the privilege escalation risk: if you can write into any
of the same directories you can LOAD from, the risk exists. (And
detecting whether two paths overlap is very hard in general, considering
directory symlinks, AFS mounts, etc, so we probably couldn't hope to
forbid LOADing from any writable directory.)

regards, tom lane