Re: Updated instrumentation patch

> > Per recent discussion, here is yet another updated version of the
> > instrumentation patch. Changes:
>
> > * Added guc option "disable_remote_admin", that disables any write
> > operations (write, unlink, rename) even for the superuser. Set as
> > PGC_POSTMASTER so it cannot be changed remotely.
>
> I was envisioning it as disabling all filesystem access ---
> read as well as write. Essentially the abstract concept I
> want is that with this on, even a superuser cannot use
> Postgres to get at the underlying operating system. A name
> like "enable_filesystem_access" would probably be more appropriate.

Um. I thought the entire argument was about *writing* files. But it
should be easy enough to stick requireRemoteAdmin() to all the
functions.

For the long term I was thinking something like "restrict_superuser",
which would disable both read and write, and COPY, and untrusted PL
creation, etc, etc. But that's not for 8.1.

> Also, as I already said, marking it as PGC_POSTMASTER is
> simply not adequate security. Once we have some sort of
> remote admin feature, I would expect it to support adjustment
> of even postmaster-level options (this would mean forcing a
> database restart of course) --- you can hardly say that you
> have a complete remote admin solution if you can't change
> shared_buffers or max_connections.

The point is you cannot *enable* it once it is *disabled*. Thus you
cannot *elevate* your privileges. Thus not a security issue.

Yes, if it is enabled, you can remotely disbale it and lock yourself
out. But you can *not* do it the other way around. Once it's off, you
need shell access on the box to edit the file and re-enable it.

Once we have a "real remote admin API", it becomes an argument, and it
will have to be adjusted. But we don't have that today, and I see no
need to create a new guc category just for this. After all, some of
these functions will probably go away completely once we have such an
API.

//Magnus