Re: Thoughts on the location of configuration files

On Tuesday 18 December 2001 11:50 pm, Tom Lane wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)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