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

Wouldn't installing postgreSQL as postgres give me the convenience to
upgrade PostgreSQL and the database without having the SA get involved.
Is it a question of roles now? Should a DBA perform all
postgreSQL-related tasks or should that the accountability be confused
by having SA responsible for some DB tasks such as the installation and
upgrades and the DBA responsible for the rest.. What do you think?

--
Husam

-----Original Message-----
From: pgsql-admin-owner(at)postgresql(dot)org
[mailto:pgsql-admin-owner(at)postgresql(dot)org] On Behalf Of Uwe C. Schroeder
Sent: Thursday, January 13, 2005 2:47 PM
To: Bruce Momjian
Cc: PostgreSQL Admin
Subject: Re: [ADMIN] Installing PostgreSQL as "postgress" versus "root"
Debate!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 13 January 2005 01:44 pm, Bruce Momjian wrote:
> Uwe C. Schroeder wrote:
> [ PGP not available, raw data follows ]
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Thursday 13 January 2005 10:52 am, Goulet, Dick wrote:
> > > Doug,
> > >
> > > OK, Assume that the binaries are installed under root, but a
> > > hacker cracks PostGres, what is to stop him/her from trashing all
> > > of the database files in the first place? Their not owned by
root.
> > > Installing malware, whether it's actual code or
> > > destroying/defacing files causes similar if not identical
> > > problems. At least their restricted to the postgres user. And in

> > > my book the executables are of zero value whereas the data files,
> > > and their contained data, are of infinite value. So under your
> > > scheme we're protecting the least valuable part of the system at
the expense of the most valuable.
> >
> > So where is the difference? If all executables AND the data is under

> > the postgres account - an intruder hacking the postgres account
> > would still be able to destroy your data.
>
> To me the difference is that if you your postgres account is hacked
> and you installed as root you can delete your /data and start over
> knowing the rest of your install is OK. If your binaries are owned by

> postgres, you have to reinstall too.
>
> Of course you might as well reinstall anyway but there is a difference

> in knowing the state of the non-/data files.

You're right on that one. Although I had a machine hacked a while back
(well, I missed updating the flawed ssh version on there). The hacker
wasn't really interested in the data, he just wanted another machine to
start attacks from
- - however he managed to install a rootkit. In the case one of my
machines is hacked I generally scratch the whole machine and reinstall
it. There are so many ways to mess with the machine that I'm not
willing to take the risk missing something the hacker left behind.
It would be time to suggest to the linux kernel developers what BSD had
for a long time: The nice flag to lock files even for root access. The
only way to set or reset that flag on BSD is to shut the machine down in
single user mode. If you flag all binaries and configuration files you
can be pretty sure that even with a rootkit the hacker doesn't get far
:-) On the other hand it's not very good for machines that have to be up
24/7, so this extra security comes at the trade off on downtime to
reconfigure something.

UC

- --
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFB5vpljqGXBvRToM4RAikmAJ9aTriTSiy94HHexI0pIvPwX3IuuQCfeIlD
BQvYK+N9jg+IDHN1ESS8Yr0=
=XrtC
-----END PGP SIGNATURE-----

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org
**********************************************************************
This message contains confidential information intended only for the
use of the addressee(s) named above and may contain information that
is legally privileged. If you are not the addressee, or the person
responsible for delivering it to the addressee, you are hereby
notified that reading, disseminating, distributing or copying this
message is strictly prohibited. If you have received this message by
mistake, please immediately notify us by replying to the message and
delete the original message immediately thereafter.

Thank you. FADLD Tag
**********************************************************************