Re: Summary of new configuration file and data directory

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Summary of new configuration file and data directory
Date: 2002-02-08 17:08:37
Message-ID: Pine.LNX.4.30.0202071734070.683-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 this happen:

a. Make the configuration files world-readable. For the SSL
certificate files and the secondary password files, you should not
use this method. For other configuration files, this is safe, but
if your authentication setup is insecure, everyone will be able to
see that and exploit it easily. [Gratuitous comment about security
through obscurity 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 files group
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 considered desirable
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(at)gmx(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2002-02-08 17:09:16 Re: Database abstration layers
Previous Message Tom Lane 2002-02-08 17:00:12 Re: GiST on 64-bit box