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

Re: Installing PostgreSQL as "postgress" versus "root"

From: "Goulet, Dick" <DGoulet(at)vicr(dot)com>
To: "Scott Marlowe" <smarlowe(at)g2switchworks(dot)com>,"Dawid Kuroczko" <qnex42(at)gmail(dot)com>
Cc: <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Installing PostgreSQL as "postgress" versus "root"
Date: 2005-01-14 16:16:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin

	Now add two managers who are more at home with HP MPE or VAX VMS
and a CIO whose more comfortable in software development & you'll see
why I am the way I am.  Paranoia & irrational thought are everywhere. 

Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-----Original Message-----
From: Scott Marlowe [mailto:smarlowe(at)g2switchworks(dot)com] 
Sent: Thursday, January 13, 2005 12:19 PM
To: Dawid Kuroczko
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: [ADMIN] Installing PostgreSQL as "postgress" versus "root"

On Thu, 2005-01-13 at 06:41, Dawid Kuroczko wrote:
> On Thu, 13 Jan 2005 12:20:41 +0000, Dick Davies
> <rasputnik(at)hellooperator(dot)net> wrote:
> > > But only if either setuid root or executed by root.  Hey, on my
> > > system even /bin/sh is owned by root; it would be funny of it
> > > executed as root
> > C'mon folks, the guy obviously made a booboo - no need to rub his
> > nose in it...
> I apologize if it felt like it.  Anyway, I've been thinking about it a
> if pgsql files are owned by pgsql and some BAD user with too high
> privileges (say, plperlU or other unrestricted access), she can modify
> database files (like remove everything from data directory, etc.), and
> it matters little if files are owned by root or postgres -- the
> data is owned by postgres.
> However, if she is really BAD, she can prepare her own version of say,
> psql binary (which will "invisibly" grant her access to all victims
> for instance) and overwrite PostgreSQL's original version with her
> If the files are owned by root, she cannot do it (though she can try
> making postgres suid shell binary in /tmp, etc. etc. etc.). :-)

The real danger here shows up in daemons that are started by root by the
necessity of opening a port <1024, like apache.  These processes then
change to another user once running, or for the spawned children. 
Imagine that apache was installed under the httpd user, not root.  

Since the httpd user would then own the httpd binary, it is possible
that if someone were to get the httpd daemon to write over the
/bin/httpd file, that upon startup, the root user attempting to execute
the httpd daemon could be running someone else's code with roots

This isn't a problem for postgresql, since it is started by a non-root
user from the beginning.

I too have had to deal with auditors whose understanding of security,
and unix security in particular, was sub optimal, so I kow what Dick
here is talking about on that account.  In fact I had one arguing this
exact same point five or so years ago about our apace installation, and
it took nearly all day to point out the flaw in his logic and get him to
sign off on my installation.

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

pgsql-admin by date

Next:From: Richard_D_LevineDate: 2005-01-14 16:22:18
Subject: Re: Cron DB Bounce causes index problems && Help rotating logs
Previous:From: Chris HooverDate: 2005-01-14 15:16:52
Subject: Cron DB Bounce causes index problems && Help rotating logs

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