> >> 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?)
If you make it a postmaster-start-only, and it restricts the
remote-admin-functionality, then you will not be able to change it
remotely.
Making it a GUC makes it a whole lot easier to deal with for the admin -
especially in cases like win32 when it's not as easy to edit the startup
parameters for service based processes.
> > 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.)
Right. That's gotta be at least as bad as dealing with URLs, and we've
seen how many bugs there have been in those in pretty much all
webservers...
//Magnus
