Thread: Installing PostgreSQL as "postgress" versus "root" Debate!
I've seen book that prefer installing PostgreSQL as root and another one recommends otherwise by first creating a postgres account and then installing it as postgres. In the Oracle world, you don't use root to install the software. What is the best practice as far as PostgreSQL goes? -- Husam ********************************************************************** 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 **********************************************************************
Tomeh, Husam wrote: > > > I've seen book that prefer installing PostgreSQL as root and another one > recommends otherwise by first creating a postgres account and then > installing it as postgres. In the Oracle world, you don't use root to > install the software. What is the best practice as far as PostgreSQL > goes? Create your postgres user Install Postgres make sure postgres user owns everything use postgres user > > -- > Husam > ********************************************************************** > 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 > ********************************************************************** > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Command Prompt, Inc., your source for PostgreSQL replication, professional support, programming, managed services, shared and dedicated hosting. Home of the Open Source Projects plPHP, plPerlNG, pgManage, and pgPHPtoolkit. Contact us now at: +1-503-667-4564 - http://www.commandprompt.com
Attachment
On Wed, 12 Jan 2005 15:30:06 -0800, Tomeh, Husam <htomeh@firstam.com> wrote: > I've seen book that prefer installing PostgreSQL as root and another one > recommends otherwise by first creating a postgres account and then > installing it as postgres. In the Oracle world, you don't use root to > install the software. What is the best practice as far as PostgreSQL > goes? There is absolutely no reason to install as root. I always create a user (for me, it's 'pgsql') and then run the installer as that user. That does mean that the directory (/usr/local/pgsql/) must already be created and owned (it's the home for my user). The less done as root, the better. Chris -- | Christopher Petrilli | petrilli@gmail.com
Tomeh, Husam wrote: > I've seen book that prefer installing PostgreSQL as root and another > one recommends otherwise by first creating a postgres account and > then installing it as postgres. In the Oracle world, you don't use > root to install the software. What is the best practice as far as > PostgreSQL goes? The current recommendation, which is reflected in the installation instructions, is to install the software as root and to use the postgres user for the database files. The advice seen elsewhere in this thread to use the postgres user also for the software files is wrong. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Thu, 13 Jan 2005 01:00:31 +0100, Peter Eisentraut <peter_e@gmx.net> wrote: > Tomeh, Husam wrote: > > I've seen book that prefer installing PostgreSQL as root and another > > one recommends otherwise by first creating a postgres account and > > then installing it as postgres. In the Oracle world, you don't use > > root to install the software. What is the best practice as far as > > PostgreSQL goes? > > The current recommendation, which is reflected in the installation > instructions, is to install the software as root and to use the > postgres user for the database files. The advice seen elsewhere in > this thread to use the postgres user also for the software files is > wrong. As a security professional, why would the root user need to be involved in the ownership of PostgreSQL? I see no reason for this, but perhaps I'm missing something important. Chris -- | Christopher Petrilli | petrilli@gmail.com
Peter Eisentraut wrote: > Tomeh, Husam wrote: > >>I've seen book that prefer installing PostgreSQL as root and another >>one recommends otherwise by first creating a postgres account and >>then installing it as postgres. In the Oracle world, you don't use >>root to install the software. What is the best practice as far as >>PostgreSQL goes? > > > The current recommendation, which is reflected in the installation > instructions, is to install the software as root and to use the > postgres user for the database files. The advice seen elsewhere in > this thread to use the postgres user also for the software files is > wrong. If the user owns the catalog, there is no reason for that user to not also own the files. Sincerely, Joshua D. Drake > -- Command Prompt, Inc., your source for PostgreSQL replication, professional support, programming, managed services, shared and dedicated hosting. Home of the Open Source Projects plPHP, plPerlNG, pgManage, and pgPHPtoolkit. Contact us now at: +1-503-667-4564 - http://www.commandprompt.com
Attachment
On January 12, 2005 04:31 pm, Joshua D. Drake wrote: > Peter Eisentraut wrote: > > Tomeh, Husam wrote: > >>I've seen book that prefer installing PostgreSQL as root and another > >>one recommends otherwise by first creating a postgres account and > >>then installing it as postgres. In the Oracle world, you don't use > >>root to install the software. What is the best practice as far as > >>PostgreSQL goes? > > > > The current recommendation, which is reflected in the installation > > instructions, is to install the software as root and to use the > > postgres user for the database files. The advice seen elsewhere in > > this thread to use the postgres user also for the software files is > > wrong. > > If the user owns the catalog, there is no reason for that user to not > also own the files. > > Sincerely, > > Joshua D. Drake Isn't there a requiremnet of writing libpq.so to a location that ldconfig can make use of it? By default FreeBSD won't let you ldconfig a file that isn't owned by root (or that is in a directory that is writeable by anybody other than members of group 0). -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com
>>The current recommendation, which is reflected in the installation >>instructions, is to install the software as root and to use the >>postgres user for the database files. The advice seen elsewhere in >>this thread to use the postgres user also for the software files is >>wrong. >> >> > >As a security professional, why would the root user need to be >involved in the ownership of PostgreSQL? > The root does not need to be involved. You don't even have to be root to install it ;). The only possible reason I can come up with is that if the root user (or any other user for that matter) owns the installation files, then the postgres user would not be able to accidently delete something. Sincerely, Joshua D. Drake > I see no reason for this, >but perhaps I'm missing something important. > >Chris > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment
Darcy Buskermolen wrote: >On January 12, 2005 04:31 pm, Joshua D. Drake wrote: > > >>Peter Eisentraut wrote: >> >> >>>Tomeh, Husam wrote: >>> >>> >>>>I've seen book that prefer installing PostgreSQL as root and another >>>>one recommends otherwise by first creating a postgres account and >>>>then installing it as postgres. In the Oracle world, you don't use >>>>root to install the software. What is the best practice as far as >>>>PostgreSQL goes? >>>> >>>> >>>The current recommendation, which is reflected in the installation >>>instructions, is to install the software as root and to use the >>>postgres user for the database files. The advice seen elsewhere in >>>this thread to use the postgres user also for the software files is >>>wrong. >>> >>> >>If the user owns the catalog, there is no reason for that user to not >>also own the files. >> >>Sincerely, >> >>Joshua D. Drake >> >> > >Isn't there a requiremnet of writing libpq.so to a location that ldconfig can >make use of it? By default FreeBSD won't let you ldconfig a file that isn't >owned by root (or that is in a directory that is writeable by anybody other >than members of group 0). > > Now that is interesting. That is not a problem on Linux. I didn't know that FreeBSD was like that. Sincerely, Joshua D. Drake > > > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment
Christopher Petrilli <petrilli@gmail.com> writes:
> On Thu, 13 Jan 2005 01:00:31 +0100, Peter Eisentraut <peter_e@gmx.net> wrote:
>> The current recommendation, which is reflected in the installation
>> instructions, is to install the software as root and to use the
>> postgres user for the database files. The advice seen elsewhere in
>> this thread to use the postgres user also for the software files is
>> wrong.
> As a security professional, why would the root user need to be
> involved in the ownership of PostgreSQL? I see no reason for this,
> but perhaps I'm missing something important.
The rationale is that the executables should not be owned by the
postgres user, so that they can't be corrupted/trojaned if someone
manages to break in via the database server.
This of course does not require that the executables be owned by root,
only by someone other than the daemon account you run the server under.
regards, tom lane
Peter,
You may well be on the development team, but you are wrong for
one very important reason. If the Postgresql executables are owned by
root they execute with the priviledges of root. Thereby any local
created extensions like database_size also execute with the priviledges
of root. Wouldn't it be wonderful if some disgruntled person or a
hacker wrote & installed a package that did an rm -fr /?? Install
Postgres in it's own account where it's priviledges to destroy the
server are restricted. Anything else is begging for trouble.
Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-----Original Message-----
From: Peter Eisentraut [mailto:peter_e@gmx.net]
Sent: Wednesday, January 12, 2005 7:01 PM
To: Tomeh, Husam
Cc: PgSQL ADMIN
Subject: Re: [ADMIN] Installing PostgreSQL as "postgress" versus "root"
Debate!
Tomeh, Husam wrote:
> I've seen book that prefer installing PostgreSQL as root and another
> one recommends otherwise by first creating a postgres account and
> then installing it as postgres. In the Oracle world, you don't use
> root to install the software. What is the best practice as far as
> PostgreSQL goes?
The current recommendation, which is reflected in the installation
instructions, is to install the software as root and to use the
postgres user for the database files. The advice seen elsewhere in
this thread to use the postgres user also for the software files is
wrong.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> Peter, > > You may well be on the development team, but you are wrong for > one very important reason. If the Postgresql executables are owned by > root they execute with the priviledges of root. Thereby any local > created extensions like database_size also execute with the priviledges > of root. Wouldn't it be wonderful if some disgruntled person or a > hacker wrote & installed a package that did an rm -fr /?? Install > Postgres in it's own account where it's priviledges to destroy the > server are restricted. Anything else is begging for trouble. Actually this is not true at any level. In order for the file to execute as root it must be setuid root, the ownership is irrelevant at that point. If what you said were true, then almost every binary on a Linux system would execute as root. Sincerely, Joshua D. Drake > > > Dick Goulet > Senior Oracle DBA > Oracle Certified 8i DBA > -----Original Message----- > From: Peter Eisentraut [mailto:peter_e@gmx.net] > Sent: Wednesday, January 12, 2005 7:01 PM > To: Tomeh, Husam > Cc: PgSQL ADMIN > Subject: Re: [ADMIN] Installing PostgreSQL as "postgress" versus "root" > Debate! > > Tomeh, Husam wrote: >> I've seen book that prefer installing PostgreSQL as root and another >> one recommends otherwise by first creating a postgres account and >> then installing it as postgres. In the Oracle world, you don't use >> root to install the software. What is the best practice as far as >> PostgreSQL goes? > > The current recommendation, which is reflected in the installation > instructions, is to install the software as root and to use the > postgres user for the database files. The advice seen elsewhere in > this thread to use the postgres user also for the software files is > wrong. > > -- Co-Founder Command Prompt, Inc. The wheel's spinning but the hamster's dead
On Wed, 12 Jan 2005, Goulet, Dick wrote: > You may well be on the development team, but you are wrong for > one very important reason. If the Postgresql executables are owned by > root they execute with the priviledges of root. Thereby any local Not on any reasonable system unless installed setuid at which point I don't think they'd run since I think the don't run as root code would prevent it.
Whatever, I'll keep root only for absolutely restricted use & install under a separate user account. Works just fine & it makes the auditors & sysadmin feel better. Dick Goulet Senior Oracle DBA Oracle Certified 8i DBA -----Original Message----- From: Stephan Szabo [mailto:sszabo@megazone.bigpanda.com] Sent: Wednesday, January 12, 2005 11:14 PM To: Goulet, Dick Cc: Peter Eisentraut; Tomeh, Husam; PgSQL ADMIN Subject: Re: [ADMIN] Installing PostgreSQL as "postgress" versus "root" Debate! On Wed, 12 Jan 2005, Goulet, Dick wrote: > You may well be on the development team, but you are wrong for > one very important reason. If the Postgresql executables are owned by > root they execute with the priviledges of root. Thereby any local Not on any reasonable system unless installed setuid at which point I don't think they'd run since I think the don't run as root code would prevent it.
Goulet, Dick wrote: > Peter, > > You may well be on the development team, but you are wrong for > one very important reason. If the Postgresql executables are owned by > root they execute with the priviledges of root. Thereby any local What? They are not setuid? --------------------------------------------------------------------------- > created extensions like database_size also execute with the priviledges > of root. Wouldn't it be wonderful if some disgruntled person or a > hacker wrote & installed a package that did an rm -fr /?? Install > Postgres in it's own account where it's priviledges to destroy the > server are restricted. Anything else is begging for trouble. > > > Dick Goulet > Senior Oracle DBA > Oracle Certified 8i DBA > -----Original Message----- > From: Peter Eisentraut [mailto:peter_e@gmx.net] > Sent: Wednesday, January 12, 2005 7:01 PM > To: Tomeh, Husam > Cc: PgSQL ADMIN > Subject: Re: [ADMIN] Installing PostgreSQL as "postgress" versus "root" > Debate! > > Tomeh, Husam wrote: > > I've seen book that prefer installing PostgreSQL as root and another > > one recommends otherwise by first creating a postgres account and > > then installing it as postgres. In the Oracle world, you don't use > > root to install the software. What is the best practice as far as > > PostgreSQL goes? > > The current recommendation, which is reflected in the installation > instructions, is to install the software as root and to use the > postgres user for the database files. The advice seen elsewhere in > this thread to use the postgres user also for the software files is > wrong. > > -- > Peter Eisentraut > http://developer.postgresql.org/~petere/ > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Wed, 12 Jan 2005, Goulet, Dick wrote: > Whatever, I'll keep root only for absolutely restricted use & install > under a separate user account. Works just fine & it makes the auditors > & sysadmin feel better. Unfortunately, I _know_ how auditors think, but I would hope that a sensible company would have admins that know better. After a few years in that role... ah, probably better not to say. If you stop and look at the binaries you use as that separate account to do, well, just about anything - specifically who owns them, and why, you might find a few interesting thoughts about how actual unix security works bubbling around. But this is just technical advice, not career advice. -j, glad to be where he is now. -- Jamie Lawrence jal@jal.org I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. - Umberto Eco
Goulet, Dick wrote: >Whatever, I'll keep root only for absolutely restricted use & install >under a separate user account. Works just fine & it makes the auditors >& sysadmin feel better. > > I don't argue the point of using root. I agree with you there. Just the point that if it is owned by root it executes as root. Sincerely, Joshua D. Drake > >Dick Goulet >Senior Oracle DBA >Oracle Certified 8i DBA >-----Original Message----- >From: Stephan Szabo [mailto:sszabo@megazone.bigpanda.com] >Sent: Wednesday, January 12, 2005 11:14 PM >To: Goulet, Dick >Cc: Peter Eisentraut; Tomeh, Husam; PgSQL ADMIN >Subject: Re: [ADMIN] Installing PostgreSQL as "postgress" versus "root" >Debate! > >On Wed, 12 Jan 2005, Goulet, Dick wrote: > > > >> You may well be on the development team, but you are wrong for >>one very important reason. If the Postgresql executables are owned by >>root they execute with the priviledges of root. Thereby any local >> >> > >Not on any reasonable system unless installed setuid at which point I >don't think they'd run since I think the don't run as root code would >prevent it. > >---------------------------(end of broadcast)--------------------------- >TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment
Christopher Petrilli <petrilli@gmail.com> writes: > As a security professional, why would the root user need to be > involved in the ownership of PostgreSQL? I see no reason for this, > but perhaps I'm missing something important. A number of years ago some Unices experimented with installing system binaries with owners other than root. Owner 'bin' was one common try. Superficially this sounds good, but experience has shown that it is a bad idea. I don't think anyone does this any longer. Cracking root will compromise standard Unix security no matter who owns the binaries. If system binaries are owned by a user other than root, now you have at least two ids you must protect at all costs. By making things more complex you've just managed to make your job of maintaining security at least twice as hard as it would have been if you had left things alone. Obviously considerations are very different if setuid and setgid programs are involved. Some modern Unices have more advanced security models than the traditional Unix model, so binary ownership may be handled differently in them as well. Mark Twain understood this clearly all the way back in 1894: "Put all your eggs in one basket, and WATCH THAT BASKET."
I wrote: > The current recommendation, which is reflected in the installation > instructions, is to install the software as root and to use the > postgres user for the database files. The advice seen elsewhere in > this thread to use the postgres user also for the software files is > wrong. Those who dismiss this advice as my own imagination may want to check how other server packages are installed on their system. What user does sshd run under? Who owns /usr/sbin/sshd? What user does the MTA run under? Who owns the binaries? What user does Apache run under? Who owns the binaries? etc. On my system, the answer is sshd/postfix/www-data on the one side and root on the other. Therefore it is consistent to use postgres and root for PostgreSQL. If your system uses a different distribution of users, you may want to adjust the PostgreSQL installation accordingly. But note that this voids your warranty because it is not covered by the installation instructions. :) -- Peter Eisentraut http://developer.postgresql.org/~petere/
Goulet, Dick írta: >Peter, > > You may well be on the development team, but you are wrong for >one very important reason. If the Postgresql executables are owned by >root they execute with the priviledges of root. Thereby any local >created extensions like database_size also execute with the priviledges >of root. Wouldn't it be wonderful if some disgruntled person or a >hacker wrote & installed a package that did an rm -fr /?? Install >Postgres in it's own account where it's priviledges to destroy the >server are restricted. Anything else is begging for trouble. > > >Dick Goulet >Senior Oracle DBA >Oracle Certified 8i DBA >-----Original Message----- >From: Peter Eisentraut [mailto:peter_e@gmx.net] >Sent: Wednesday, January 12, 2005 7:01 PM >To: Tomeh, Husam >Cc: PgSQL ADMIN >Subject: Re: [ADMIN] Installing PostgreSQL as "postgress" versus "root" >Debate! > >Tomeh, Husam wrote: > > >>I've seen book that prefer installing PostgreSQL as root and another >>one recommends otherwise by first creating a postgres account and >>then installing it as postgres. In the Oracle world, you don't use >>root to install the software. What is the best practice as far as >>PostgreSQL goes? >> >> > >The current recommendation, which is reflected in the installation >instructions, is to install the software as root and to use the >postgres user for the database files. The advice seen elsewhere in >this thread to use the postgres user also for the software files is >wrong. > > > Sorry, but under the UNIX security modell each process (except special seteuid and setruid calls) get loaded, with the priviledges of the process which loaded it. Just try executing postmaster as an ordinary user, you will see, that it won't be able to access its data files. Cheers Geza
On Wed, 12 Jan 2005 20:52:16 -0800, Joshua D. Drake
<jd@commandprompt.com> wrote:
> >Whatever, I'll keep root only for absolutely restricted use & install
> >under a separate user account. Works just fine & it makes the auditors
> >& sysadmin feel better.
> I don't argue the point of using root. I agree with you there.
> Just the point that if it is owned by root it executes as root.
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
I see one reason to use 'postgres' as the install user -- to give
access to psql binaries to group of users (say, members of
postgres group). But I think PostgreSQL's own permission
system is enough for the job. :)
Regards,
Dawid
* Dawid Kuroczko <qnex42@gmail.com> [0117 12:17]:
> On Wed, 12 Jan 2005 20:52:16 -0800, Joshua D. Drake
> <jd@commandprompt.com> wrote:
> > >Whatever, I'll keep root only for absolutely restricted use & install
> > >under a separate user account. Works just fine & it makes the auditors
> > >& sysadmin feel better.
> > I don't argue the point of using root. I agree with you there.
> > Just the point that if it is owned by root it executes as root.
>
> 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...
--
'Bender, Ship, stop arguing or I'll come back there and change
your opinions manually.'
-- Leela
Rasputin :: Jack of All Trades - Master of Nuns
On Thu, 13 Jan 2005 12:20:41 +0000, Dick Davies
<rasputnik@hellooperator.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 bit;
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 database
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 tables
for instance) and overwrite PostgreSQL's original version with her own.
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.). :-)
Regards,
Dawid
Well, thanks for the leeway, but getting one's nose rubbed in things for
good and bad comes with the turf. If there's one thing I've learned
about software over the years it's that there are many ways to skin the
same cat, just some are less painful than others.
Anyway, to the discussion: Commercial software, not just databases and
outside of MicroSludge, always want to be installed in their own user
accounts. PostGreSql does not recommend the same since it recommends
being installed by root. This sets off auditors and sysadmins,
especially those with little open source experience. Management is not
too happy about it as well, nor are security folks. It's a simple
matter if you don't have to access root owned software, other than
operating system installed, then "things must be safer". I'll admit to
being part of that culture and having a bias. I like having root
restricted, including making it impossible to login to root except
through the system console or via su. Means that to break in from
outside you've got to break two accounts, not one. That leads it self
to Postgres install as well. I as the DBA should be able to install,
upgrade, etc the software without access to the root account. Simply
put the fewer people who know the root password the fewer who can
destroy the system and the fewer who have to be told when the password
changes. And the fewer people who know anything, the more secure it is.
Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-----Original Message-----
From: Dick Davies [mailto:rasputnik@hellooperator.net]
Sent: Thursday, January 13, 2005 7:21 AM
To: PostgreSQL Admin
Subject: Re: [ADMIN] Installing PostgreSQL as "postgress" versus "root"
Debate!
* Dawid Kuroczko <qnex42@gmail.com> [0117 12:17]:
> On Wed, 12 Jan 2005 20:52:16 -0800, Joshua D. Drake
> <jd@commandprompt.com> wrote:
> > >Whatever, I'll keep root only for absolutely restricted use &
install
> > >under a separate user account. Works just fine & it makes the
auditors
> > >& sysadmin feel better.
> > I don't argue the point of using root. I agree with you there.
> > Just the point that if it is owned by root it executes as root.
>
> 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...
--
'Bender, Ship, stop arguing or I'll come back there and change
your opinions manually.'
-- Leela
Rasputin :: Jack of All Trades - Master of Nuns
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
>Those who dismiss this advice as my own imagination may want to check >how other server packages are installed on their system. > >What user does sshd run under? Who owns /usr/sbin/sshd? > >What user does the MTA run under? Who owns the binaries? > >What user does Apache run under? Who owns the binaries? > >etc. > > Peter is correct on this. Most daemon level items typically run as their own user to protect the rest of the system. Sincerely, Joshua D. Drake >On my system, the answer is sshd/postfix/www-data on the one side and >root on the other. Therefore it is consistent to use postgres and root >for PostgreSQL. If your system uses a different distribution of users, >you may want to adjust the PostgreSQL installation accordingly. But >note that this voids your warranty because it is not covered by the >installation instructions. :) > > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment
"Goulet, Dick" <DGoulet@vicr.com> writes: > to Postgres install as well. I as the DBA should be able to install, > upgrade, etc the software without access to the root account. Simply > put the fewer people who know the root password the fewer who can > destroy the system and the fewer who have to be told when the password > changes. And the fewer people who know anything, the more secure it is. This analysis is incomplete. Under this scheme, if someone cracks your account they can install trojaned or malicious executables owned by you without cracking root. The flaw is in believing that this scheme requires an intruder to crack two accounts to defeat your security. In fact, you have doubled the number of targets but left the amount of work required of the bad guys to compromise your system the same (crack one account). Put all your eggs in one basket, and WATCH THAT BASKET.
On Thu, 2005-01-13 at 06:41, Dawid Kuroczko wrote: > On Thu, 13 Jan 2005 12:20:41 +0000, Dick Davies > <rasputnik@hellooperator.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 bit; > 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 database > 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 tables > for instance) and overwrite PostgreSQL's original version with her own. > > 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 privileges. 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.
* Dawid Kuroczko <qnex42@gmail.com> [0151 12:51]:
> On Thu, 13 Jan 2005 12:20:41 +0000, Dick Davies
> <rasputnik@hellooperator.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.
Not really, i just thought the whole list would be joining in before long.
> Anyway, I've been thinking about it a bit;
> 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 database
> data is owned by postgres.
Surely plperlu runs as the postgres user, not root?
(haven't got further than a few sequences yet, I'm an sql noob).
Removing database files isn't the same as replacing system binaries.
But you're right, psql (etc) in ~pgsql [which you have to do if you don't have
privileges to install anywhere else] sounds pretty dumb to me - then all local users
need to be able to read the database directories. So let's all stick with root
installs and be happy :)
--
'That question was less stupid; though you asked it in a profoundly stupid way.'
-- Prof. Farnsworth
Rasputin :: Jack of All Trades - Master of Nuns
>Put all your eggs in one basket, and WATCH THAT BASKET. > > > Better yet, pay someone more reliable than oneself to watch it. Preferably a well-paid and happy fox. Or _maybe_ put your eggs in an invisible super-basket? Not trolling, just checking the analogy integrity field. M
Martha Stewart called it a Good Thing when DGoulet@vicr.com ("Goulet, Dick") wrote:
> You may well be on the development team, but you are wrong for
> one very important reason. If the Postgresql executables are owned by
> root they execute with the priviledges of root.
Methinks you may not understand Unix permissions as well as you need
to.
Binaries only execute with the privileges of root if:
a) They are being run by the root user, or
b) They are owned by root and have the "setuid" bit set.
--
"cbbrowne","@","gmail.com"
http://cbbrowne.com/info/linux.html
Rules of the Evil Overlord #75. "I will instruct my Legions of Terror
to attack the hero en masse, instead of standing around waiting while
members break off and attack one or two at a time."
<http://www.eviloverlord.com/>
In an attempt to throw the authorities off his trail, htomeh@firstam.com ("Tomeh, Husam") transmitted:
> I've seen book that prefer installing PostgreSQL as root and another one
> recommends otherwise by first creating a postgres account and then
> installing it as postgres. In the Oracle world, you don't use root to
> install the software. What is the best practice as far as PostgreSQL
> goes?
"Best practices" tend to vary.
If you are installing software using "package management" tools, then
it is mandatory that you install it as some form of "administrative"
user (e.g. - root) because typical package management tools require
root access.
(That's true whether we're talking about the RPM package manager that
Caldera paid RHAT to develop, dpkg used by Debian, BSD Ports, or
pkgadd used by sundry systems.)
I happen to do much of my work in "managed hosting" environments where
I may not even have root access. In those environments, the "best
practice" is the "mandatory practice" and is to get a postgres user
set up and to have that user install the software.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://www.ntlug.org/~cbbrowne/emacs.html
Rules of the Evil Overlord #94. "When arresting prisoners, my guards
will not allow them to stop and grab a useless trinket of purely
sentimental value." <http://www.eviloverlord.com/>
Martha Stewart called it a Good Thing when DGoulet@vicr.com ("Goulet, Dick") wrote:
> Well, thanks for the leeway, but getting one's nose rubbed in things for
> good and bad comes with the turf. If there's one thing I've learned
> about software over the years it's that there are many ways to skin the
> same cat, just some are less painful than others.
>
> Anyway, to the discussion: Commercial software, not just databases
> and outside of MicroSludge, always want to be installed in their own
> user accounts. PostGreSql does not recommend the same since it
> recommends being installed by root. This sets off auditors and
> sysadmins, especially those with little open source experience.
> Management is not too happy about it as well, nor are security
> folks.
Excuse me?
Where is there any such recommendation?
The one place which documents this is the following:
<http://www.postgresql.org/docs/7.4/static/install-procedure.html>
----------------------------------------------------------------------
"To install PostgreSQL enter
gmake install
This will install files into the directories that were specified in
step 1. Make sure that you have appropriate permissions to write into
that area. Normally you need to do this step as root. Alternatively,
you could create the target directories in advance and arrange for
appropriate permissions to be granted."
----------------------------------------------------------------------
That does not _recommend_ having root install the software; it says
"Normally you need to do this step as root" which does not look like a
recommendation to me.
--
(reverse (concatenate 'string "moc.liamg" "@" "enworbbc"))
http://cbbrowne.com/info/oses.html
Rules of the Evil Overlord #157. "Whenever plans are drawn up that
include a time-table, I'll post-date the completion 3 days after it's
actually scheduled to occur and not worry too much if they get
stolen." <http://www.eviloverlord.com/>
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.
Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-----Original Message-----
From: Doug Quale [mailto:quale1@charter.net]
Sent: Thursday, January 13, 2005 11:56 AM
To: PostgreSQL Admin
Subject: Re: [ADMIN] Installing PostgreSQL as "postgress" versus "root"
Debate!
"Goulet, Dick" <DGoulet@vicr.com> writes:
> to Postgres install as well. I as the DBA should be able to install,
> upgrade, etc the software without access to the root account. Simply
> put the fewer people who know the root password the fewer who can
> destroy the system and the fewer who have to be told when the password
> changes. And the fewer people who know anything, the more secure it
is.
This analysis is incomplete. Under this scheme, if someone cracks
your account they can install trojaned or malicious executables owned
by you without cracking root. The flaw is in believing that this
scheme requires an intruder to crack two accounts to defeat your
security. In fact, you have doubled the number of targets but left
the amount of work required of the bad guys to compromise your system
the same (crack one account).
Put all your eggs in one basket, and WATCH THAT BASKET.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
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. The root user can not own postgres data files. The main super user which can be any user except root (uid 0) is who owns the data files which is determined at the runtime of initdb. Sincerely, Joshua D. Drake > > > Dick Goulet > Senior Oracle DBA > Oracle Certified 8i DBA > -----Original Message----- > From: Doug Quale [mailto:quale1@charter.net] > Sent: Thursday, January 13, 2005 11:56 AM > To: PostgreSQL Admin > Subject: Re: [ADMIN] Installing PostgreSQL as "postgress" versus "root" > Debate! > > "Goulet, Dick" <DGoulet@vicr.com> writes: > > >>to Postgres install as well. I as the DBA should be able to install, >>upgrade, etc the software without access to the root account. Simply >>put the fewer people who know the root password the fewer who can >>destroy the system and the fewer who have to be told when the password >>changes. And the fewer people who know anything, the more secure it > > is. > > This analysis is incomplete. Under this scheme, if someone cracks > your account they can install trojaned or malicious executables owned > by you without cracking root. The flaw is in believing that this > scheme requires an intruder to crack two accounts to defeat your > security. In fact, you have doubled the number of targets but left > the amount of work required of the bad guys to compromise your system > the same (crack one account). > > Put all your eggs in one basket, and WATCH THAT BASKET. > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Command Prompt, Inc., your source for PostgreSQL replication, professional support, programming, managed services, shared and dedicated hosting. Home of the Open Source Projects plPHP, plPerlNG, pgManage, and pgPHPtoolkit. Contact us now at: +1-503-667-4564 - http://www.commandprompt.com
Attachment
On Thu, Jan 13, 2005 at 13:52:41 -0500, "Goulet, Dick" <DGoulet@vicr.com> 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. While often the data is the most valuable thing on the system, being able to modify the binaries can be leveraged to increase the level of access, since the binaries run with the uid of the person running them. So that if psql got trojaned, it could be used to update users paths and have people run trojan versions of such programs such as ssh.
Goulet, Dick wrote: > 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. No, there is no expense in that sense. We are protecting as much as possible while leaving as little as possible vulnerable. The fact that the data files are owned by postgres is merely a necessary evil because the database would otherwise be unusable. But there is no reason to have more than that owned by postgres, even if it is of little value. -- Peter Eisentraut http://developer.postgresql.org/~petere/
"Goulet, Dick" <DGoulet@vicr.com> writes: > 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. OK, suppose that I follow your suggestion. Assume that the binaries are installed under postgres, but a hacker cracks postgres. What is to stop him/her from trashing all the database files in the first place? (Nothing.) How is this different than the traditional installation where the binaries are owned by root? (It isn't, it's exactly the same.) The answer to your question doesn't provide any distinction between the traditional installation and the installation you prefer. The risks to the data are identical either way, but the risk of a trojan is less for a traditional installation than for your installation. Malware isn't restricted to the postgres user if any postgres binary is ever invoked by any user other than postgres. This might happen with psql, for example. Even if it were restricted to the postgres user, malware might still be used to collect unencrypted passwords. This problem is not identical to the dangers faced by losing data. It's data loss plus an extra worry. I agree that data security is a much bigger concern than the threat of trojaned Postgresql binaries. You are wrong, however, to think that you gain any security by having Postgresql binaries owned by a user other than root. It can be convenient to install without requiring root authority, but this convenience comes at a cost. This cost is small enough so that you may be comfortable paying it, but you should at least correctly understand the tradeoffs involved.
-----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. BTW: most commercial software needs root access to be installed - and be it just to create the user accounts. It doesn't really matter who owns the executables - if the account owning the files is hacked you're screwed anyways. When it comes to protecting the data which is the most important thing after all, replication and backup are your friends. For my larger customers I'm running replication to two offsite servers (one east-coast, one texas, just to make sure they're fine when the next earthquake hits) and I do backups every 8 hours - which are written to a tape and distributed to another set of offsite servers using rdist. So whatever happens the max they could ever possibly lose is 8 hours, except there is a full blown nuclear attack on the whole US - in which case nobody would care about the data anyways. > > > Dick Goulet > Senior Oracle DBA > Oracle Certified 8i DBA > -----Original Message----- > From: Doug Quale [mailto:quale1@charter.net] > Sent: Thursday, January 13, 2005 11:56 AM > To: PostgreSQL Admin > Subject: Re: [ADMIN] Installing PostgreSQL as "postgress" versus "root" > Debate! > > "Goulet, Dick" <DGoulet@vicr.com> writes: > > to Postgres install as well. I as the DBA should be able to install, > > upgrade, etc the software without access to the root account. Simply > > put the fewer people who know the root password the fewer who can > > destroy the system and the fewer who have to be told when the password > > changes. And the fewer people who know anything, the more secure it > > is. > > This analysis is incomplete. Under this scheme, if someone cracks > your account they can install trojaned or malicious executables owned > by you without cracking root. The flaw is in believing that this > scheme requires an intruder to crack two accounts to defeat your > security. In fact, you have doubled the number of targets but left > the amount of work required of the bad guys to compromise your system > the same (crack one account). > > Put all your eggs in one basket, and WATCH THAT BASKET. > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly - -- 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) iD4DBQFB5uSDjqGXBvRToM4RArMsAJixOHW5IxkLV2Pj838052uQh3oEAJ4oEeUZ 4v+Vdsvv905fMRhA81yQqg== =P0Py -----END PGP SIGNATURE-----
Well, someone I can wholeheartedly agree with. So it really does not matter who owns the binaries. Once the right account gets hacked your had. If they hack root your dead, if they hack postgres the database is had although the server may survive. In either case the state of your backups is your saving grace or doom. Dick Goulet Senior Oracle DBA Oracle Certified 8i DBA -----Original Message----- From: Uwe C. Schroeder [mailto:uwe@oss4u.com] Sent: Thursday, January 13, 2005 4:14 PM To: PostgreSQL Admin Subject: Re: [ADMIN] Installing PostgreSQL as "postgress" versus "root" Debate! -----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. BTW: most commercial software needs root access to be installed - and be it just to create the user accounts. It doesn't really matter who owns the executables - if the account owning the files is hacked you're screwed anyways. When it comes to protecting the data which is the most important thing after all, replication and backup are your friends. For my larger customers I'm running replication to two offsite servers (one east-coast, one texas, just to make sure they're fine when the next earthquake hits) and I do backups every 8 hours - which are written to a tape and distributed to another set of offsite servers using rdist. So whatever happens the max they could ever possibly lose is 8 hours, except there is a full blown nuclear attack on the whole US - in which case nobody would care about the data anyways.
On Thu, 2005-01-13 at 15:13, Uwe C. Schroeder wrote: > -----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. > BTW: most commercial software needs root access to be installed - and be it > just to create the user accounts. It doesn't really matter who owns the > executables - if the account owning the files is hacked you're screwed > anyways. When it comes to protecting the data which is the most important > thing after all, replication and backup are your friends. For my larger > customers I'm running replication to two offsite servers (one east-coast, one > texas, just to make sure they're fine when the next earthquake hits) and I do > backups every 8 hours - which are written to a tape and distributed to > another set of offsite servers using rdist. So whatever happens the max they > could ever possibly lose is 8 hours, except there is a full blown nuclear > attack on the whole US - in which case nobody would care about the data > anyways. Like someone pointed out, it might be quite possible to install a trojaned psql executable or some equivalent to harvest passwords, or even a version that when executed by root on accident (i.e. the sysadmin forgets he's logged in as root and runs psql) which then installs a root kit. Also, it might make it easier for a hacker to cover his tracks if he can write to the postgresql binaries.
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. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-----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-----
Re: Installing PostgreSQL as "postgress" versus "root" Debate!
From
list-pgsql-admin@news.cistron.nl ("Miquel van Smoorenburg" )
Date:
In article <4001DEAF7DF9BD498B58B45051FBEA650207ABAA@25exch1.vicorpower.vicr.com>, Goulet, Dick <DGoulet@vicr.com> wrote: > Well, someone I can wholeheartedly agree with. So it really does not >matter who owns the binaries. Once the right account gets hacked your >had. If they hack root your dead, if they hack postgres the database is >had although the server may survive. In either case the state of your >backups is your saving grace or doom. No, it's easier to hack postgres, as the database is running as the postgres user. If you allow something like PgPerl, it's even trivial. The PgPerl script runs as user postgres, and can trojan e.g. the psql executable. The next time someone (perhaps even root ... ) runs psql, they're 0wned. Now it's not that bad an idea to install postgres as a non-root user .. but use a DIFFERENT account to actually start and run postgres. That way your binaries are protected. E.g. install postgres as user 'pgbin', so that all binaries are owned by 'pgbin', then run it as user 'postgres'. Mike.