Re: Summary of new configuration file and data directory - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Summary of new configuration file and data directory
Date
Msg-id Pine.LNX.4.30.0202071734070.683-100000@peter.localdomain
Whole thread Raw
In response to Re: Summary of new configuration file and data directory locations  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Summary of new configuration file and data directory locations
List pgsql-hackers
Tom Lane writes:

> Now that I think about it, that actually seems a pretty reasonable idea.
> Just allow all the hand-maintained config files to be placed in a
> separate directory, which we treat just like $PGDATA as far as
> permissions go.  If you want a backwards-compatible setup, you need only
> set the config directory equal to $PGDATA, and you're done.

But that isn't going to satisfy anyone.  The reason that people want this
is so they can mix and match their configuration files between different
servers.  For instance, they might want to share the SSL key files between
all instances.  Or they might want different postgresql.conf files for
each server but put them all into the same directory with different names.
This was a fairly clear request in the original thread.

So the premise is that in theory any file can live anywhere.  And the
access permissions of a file are solely controlled by its own permission
bits and ownership, not what directory it may live in.  Ultimately, the
former way is more secure.

I'm not 100% comfortable either with pg_hba.conf and pg_ident.conf
world-readable by default.  The alternative is to install all
configuration files 0600 by default.  This will work painlessly for
plain-pen installations where everything is owned and run by the same
user.  If the installation and the server instance are owned by separate
users, then the installer will have to issue a few chmod/chown commands,
but he has to do that anyway right now before running initdb.  I imagine
something like this in the installation/setup procedure:

"""
1. Create a user account for the PostgreSQL server. This is the user the  server will run as. [...]

2. Make sure the user account you created in step 1 can read the  configuration files.  There are a few ways to make
thishappen:
 
  a. Make the configuration files world-readable.  For the SSL     certificate files and the secondary password files,
youshould not     use this method.  For other configuration files, this is safe, but     if your authentication setup
isinsecure, everyone will be able to     see that and exploit it easily.  [Gratuitous comment about security
throughobscurity here]
 
     $ chmod a+r /usr/local/pgsql/etc/*
  b. Change the ownership of the files to the PostgreSQL user account.
     $ chown postgres /usr/local/pgsql/etc/*
  c. Create a "postgres" group, set the group ownership of the     configuration files to that group, and make the
filesgroup     readable.
 
     $ groupadd postgres     $ usermod -G postgres postgres     $ chgrp postgres /usr/local/pgsql/etc/*     $ chmod g+r
/usr/local/pgsql/etc/*
     This setup implies that the "postgres" user does not have the     ability to write to these files, which may be
considereddesirable     or annoying.
 

3. Create a database installation with the "initdb" command.  [Continue as  usual]
"""

This would give maximum flexibility to a variety of server setups and
paranoia levels.

-- 
Peter Eisentraut   peter_e@gmx.net



pgsql-hackers by date:

Previous
From: Vince Vielhaber
Date:
Subject: Re: PostgreSQL 7.2 on SlashDot
Next
From: Tom Lane
Date:
Subject: Re: compile error of PostgreSQL 7.2 on FreeBSD-current