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

Re: Updated instrumentation patch

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Magnus Hagander <mha(at)sollentuna(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Updated instrumentation patch
Date: 2005-07-30 15:21:22
Message-ID: 200507301521.j6UFLM803939@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Magnus Hagander wrote:
> > > 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.

I think any secure solution is going to have to block all write access
to postgresql.conf, and that includes all the COPY TO and all the
untrusted languages.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-patches by date

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

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