Re: Thoughts on the location of configuration files - Mailing list pgsql-hackers

On Tuesday 18 December 2001 11:50 pm, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > As to the security points that Tom brings up, you don't put anything in
> > /etc directly -- you put it under /etc/pgsql, and lock it down the same
> > as$PGDATA.

> That'd work if we assume that /etc/pgsql can be owned by the postgres
> user.  Is that kosher per the various filesystem layout standards?

The Red-Hat-issue 'ntp' package has a /etc/ntp that is owned by ntp.ntp.  So 
there's at least precedence.  I'll have to peruse the FHS to see if it's 
parve or not.  Cursory reading indicates that it is not specified as to 
ownership in /etc.  The LSB may state something else -- I'll look at it 
later, unless someone else wants to beat me to it... :-)

However, that same standard states, about /var/lib (under which PGDATA lives, 
as the database itself is 'state information'), that users must never need to 
modify files here for configuration of program operation.  IE, the current 
RPM packages are not FHS-2.2 compliant, as postgresql.conf is under /var/lib. 
:-(

This config file change would allow compliance much more easily.

> Seems to me that someone who thinks the executables should be root-owned
> is likely to think the same of the config files.

Sorry to disappoint you :-).  No, I envision a tree where you could have:
/etc/pgsql
drwx------    1 pari           pari               4096 Nov  9 01:16 pari
drwx------    1 postgres    postgres         4096 Nov  9 01:11 main-web
drwx------    1 nobody      nobody           4096 May 15  2000 devel
drwxrwx---    1 lowen        wgcr             4096 Nov  9 22:37 wgcr

Or some such.  And the existing config files are postgres.postgres owned, 
under /var/lib/pgsql (the whole tree is postgres owned). To match the 
/etc/pgsql tree, I'd do the same in /var/lib/pgsql, with the default location 
being 'data' in order to be backward-compatible.

However, IMHO, for best security, the executables do need to be root owned.  
IMHO.  Even though none of our executables runs as root or is suid root, it 
is just a good practice to not have network-accessible executables being able 
to overwrite themselves under buffer overflow conditions.  This is procedure 
de rigeur for webservers -- at least one set of the AOLserver docs 
specifically recommends it. Of course, a webserver requires running as root 
to bind TCP port 80, but the principle is, IMHO, still valid for non-root 
unprivileged-port-binding daemons -- they shouldn't be able to scribble on 
top of themselves.

> Personally I think this would be a fine idea, I'm just worried that
> we'll find packagers overriding the decision because "the Debian
> standards don't allow you to do that" or whatever.

Oliver?  My gut feel is that Oliver would jump for joy over this proposal.  
But Oliver should answer for himself.

Red Hat doesn't have an external packaging standards document; what I've 
found I've found through the FHS, the Mandrake RPM HOWTO, and trial and error 
(the trials of error?).  Trond, Jeff Johnson, Cristian Gafton, and lots of 
actual users of my packages have taught me much more than any document has. 
:-)  Some lessons are more 'memorable' than others.....

Or, more bluntly, I don't plan on 'overriding' this -- nay, this thing would 
suit me _just_fine_. Too bad this is a post-7.2 thing.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11