Skip site navigation (1) Skip section navigation (2)

Re: Updated instrumentation patch

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Updated instrumentation patch
Date: 2005-07-30 15:16:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
> > 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

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



pgsql-patches by date

Next:From: Bruce MomjianDate: 2005-07-30 15:17:03
Subject: Re: Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL
Previous:From: Bruce MomjianDate: 2005-07-30 15:14:03
Subject: Re: Updated instrumentation patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group