Thread: Summary of new configuration file and data directory locations
Here's a concrete summary of the various proposals about the location of
configuration files and other things that have been discussed a while ago.
I think we pretty much came to agree -- if not, the rest could perhaps
better be discussed based on the following. There are also a couple of
open items that need resolution.
* postgresql.conf configuration file
Default location: ${sysconfdir}/postgresql.conf (where ${sysconfdir}
defaults to /usr/local/pgsql/etc). For those who don't know, --sysconfdir
is actually a configure option, so for "base-system" installs you can set
it to /etc if you prefer.
Overridable by:
- postmaster option -C FILENAME (not directory)
* pg_hba.conf, pg_ident.conf, secondary "password" files, SSL certificates, all other configuration things formerly in
$PGDATA
Default location: ${sysconfdir}
Overridable by postgresql.conf/GUC options (thus also
postmaster command-line options). Proposed names:
hba_conf_file
ident_conf_file
password_file_dir
ssl_key_file
ssl_certificate_file
QUESTION: Do we want to have the -C command-line option affect these
parameters in some way? It would seem quite sensible. But if -C denotes
a file name, as was requested, the location of say pg_hba.conf would be
"${directory part of -C}/pg_hba.conf" (base-name fixed), which might not
be the most elegant way.
* Permission of configuration files
By default, I like postgresql.conf, pg_hba.conf, and pg_ident.conf as
root-owned (or whatever the installer was) 0644 for ease of installation
and use. Password files containing actual passwords and the SSL files
need to be postgres-owned 0600 (or less), which will require a chmod or
chown call or two in most installations, but setting up secondary
"password" files or SSL will take a few key strokes anyway. We should
have run-time security checks that we don't use world-readable files that
contain secrets.
* Central database cluster storage area
Default location for postmaster and initdb: ${localstatedir}/data (which
defaults to /usr/local/pgsql/var/data).
Overridable by, in order of decreasing priority:
- -D option
- $PGDATA environment variable (perhaps obsolescent, but no reason to
remove it outright)
- postgresql.conf parameter
* Possible transitional aid
We could have an environment variable $PGCONF that overrides the location
of the postgresql.conf file (in some to be specified way), so those who
don't like the new setup can set PGCONF=$PGDATA or something like that.
However, since this would require the user to actually copy over all the
new configurations files from .../etc/ to $PGDATA, I don't know how many
would actually go for that.
Comments? Better ideas?
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> * pg_hba.conf, pg_ident.conf, secondary "password" files, SSL
> certificates, all other configuration things formerly in $PGDATA
> Default location: ${sysconfdir}
This strikes me as a fairly BAD idea because of the security
implications of keeping these things in a world-accessible directory.
I'm willing to tolerate moving postgresql.conf but I am much less
willing to move anything that contains sensitive information.
I suggest that the default location of these things continue to be
$PGDATA (which as you note will be settable from postgresql.conf).
> QUESTION: Do we want to have the -C command-line option affect these
> parameters in some way? It would seem quite sensible.
Not necessary if done as above.
> Password files containing actual passwords and the SSL files
> need to be postgres-owned 0600 (or less), which will require a chmod or
> chown call or two in most installations, but setting up secondary
> "password" files or SSL will take a few key strokes anyway. We should
> have run-time security checks that we don't use world-readable files that
> contain secrets.
While such a check is not a bad idea, it is really just locking the barn
door after the horse has been stolen. Better to set up the default
configuration to make such errors difficult to commit in the first place.
> We could have an environment variable $PGCONF that overrides the location
> of the postgresql.conf file (in some to be specified way), so those who
> don't like the new setup can set PGCONF=$PGDATA or something like that.
The postmaster -C switch seems sufficient for this; I don't see a reason
to invent an environment var too.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> This strikes me as a fairly BAD idea because of the security
>> implications of keeping these things in a world-accessible directory.
> I assumed sysconfdir was _not_ going to be world-accessable. Does it
> have to be?
Peter mentioned /etc as a plausible value of sysconfdir. I don't think
we should assume that it is a postgresql-only directory. Moreover,
there is little point in making these files root-owned (as he also
suggested) if they live in a postgres-owned directory; yet unless they
do, we can't use restrictive directory permissions.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I am confused why we can't just make the directory be owned by
> PostgreSQL super user with 700 permissions, like we do now with /data.
We could do it that way, but then the set of parameters Peter proposed
is quite unreasonable; there should be exactly one, namely the name of
the config directory.
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.
regards, tom lane
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
Peter Eisentraut <peter_e@gmx.net> writes:
> 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.
<<itch>> I guess my thoughts on this are colored by bad experience with
tools that are sloppy about preserving ownership/permissions on edited
files. (I can recall being burnt this way by both Emacs and HP's "SAM"
admin tool. Perhaps recent versions don't have those bugs anymore.)
I am not at all convinced that "the former way is more secure" in
reality, even if it's cleaner in theory.
Can't we do both? If the default setup is to put config files in
a Postgres-specific directory, then let's make the default arrangement
be that that directory is Postgres-owned, mode 700, *and* the config
files are Postgres-owned and mode 600. Anyone who wants to back off
from that is welcome to take responsibility for any security holes
they've created.
> 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.
I'd prefer you not recommend that at all, and certainly not as the
first alternative.
regards, tom lane
Tom Lane writes: > Can't we do both? If the default setup is to put config files in > a Postgres-specific directory, then let's make the default arrangement > be that that directory is Postgres-owned, mode 700, *and* the config > files are Postgres-owned and mode 600. The problem with this is that the PostgreSQL-specific configuration file directory may be used by programs other than the server. E.g., the ODBC driver puts stuff in there. In some future life there may be a global psqlrc file or the JDBC driver may have a global properties file (don't know if that just made sense). So we'd have to make a subdirectory, say "server" (or "secure" or "secret" ...). Seems a bit ugly. Moreover, I don't know if we can make permission changes on directories during installation (make install). (Read "can" as: ought to, while staying within the vague confines of open-source software build system standards.) For all we know, the directory may already be there and the installer told us to reuse it. How is the situation on the broken editors these days? We might just want to put a note on the top of each critical file # Make sure this file is not readable by anyone except you. # If you edit it, make sure your editor does not change the permissions on # this file. # If in doubt, execute chmod go-a filename. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Moreover, I don't know if we can make permission changes on directories
> during installation (make install). (Read "can" as: ought to, while
> staying within the vague confines of open-source software build system
> standards.) For all we know, the directory may already be there and the
> installer told us to reuse it.
Agreed, we should probably not try to change ownership/permission of an
existing directory. However, if we have to make a directory, it seems
sensible to me to make it Postgres-owned and mode 700.
Your concept of keeping client-side and server-side config files in the
same directory makes me very unhappy; that's a recipe for permission
problems if I ever saw one.
> How is the situation on the broken editors these days?
Well, I'm still using Emacs 19.34, which is a tad old, but it's got a
problem with not preserving file GIDs reliably. Dunno if this is fixed
in newer releases.
regards, tom lane
Hi guys, Quick question. I'm getting the feeling these changes will impact any company which would like to have one installation of the binaries on their servers, but which run several instances of these binaries from the one location. i.e. /opt/pgsql/7.2 <-- installed program /data1 <-- data dir and config files /data2 <-- data dir and config files /data3 <-- data dir and config files <etc> pg_ctl start -D /data1 pg_ctl start -D /data2 pg_ctl start -D /data3 :-) Regards and best wishes, Justin Clift Tom Lane wrote: > > Peter Eisentraut <peter_e@gmx.net> writes: > > 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. > > <<itch>> I guess my thoughts on this are colored by bad experience with > tools that are sloppy about preserving ownership/permissions on edited > files. (I can recall being burnt this way by both Emacs and HP's "SAM" > admin tool. Perhaps recent versions don't have those bugs anymore.) > I am not at all convinced that "the former way is more secure" in > reality, even if it's cleaner in theory. > > Can't we do both? If the default setup is to put config files in > a Postgres-specific directory, then let's make the default arrangement > be that that directory is Postgres-owned, mode 700, *and* the config > files are Postgres-owned and mode 600. Anyone who wants to back off > from that is welcome to take responsibility for any security holes > they've created. > > > 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. > > I'd prefer you not recommend that at all, and certainly not as the > first alternative. > > regards, tom lane > > ---------------------------(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 -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Did we come to a conclusion on this? --------------------------------------------------------------------------- Peter Eisentraut wrote: > Tom Lane writes: > > > Can't we do both? If the default setup is to put config files in > > a Postgres-specific directory, then let's make the default arrangement > > be that that directory is Postgres-owned, mode 700, *and* the config > > files are Postgres-owned and mode 600. > > The problem with this is that the PostgreSQL-specific configuration file > directory may be used by programs other than the server. E.g., the ODBC > driver puts stuff in there. In some future life there may be a global > psqlrc file or the JDBC driver may have a global properties file (don't > know if that just made sense). So we'd have to make a subdirectory, say > "server" (or "secure" or "secret" ...). Seems a bit ugly. > > Moreover, I don't know if we can make permission changes on directories > during installation (make install). (Read "can" as: ought to, while > staying within the vague confines of open-source software build system > standards.) For all we know, the directory may already be there and the > installer told us to reuse it. > > How is the situation on the broken editors these days? We might just want > to put a note on the top of each critical file > > # Make sure this file is not readable by anyone except you. > # If you edit it, make sure your editor does not change the permissions on > # this file. > # If in doubt, execute chmod go-a filename. > > -- > Peter Eisentraut peter_e@gmx.net > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian writes: > Did we come to a conclusion on this? I had hoped the people that originally demanded this functionality would comment in this thread. Unless someone can provide a solution that keeps the data in the configuration files safe without doing anything strange during installation, the files will stay where they are. > > --------------------------------------------------------------------------- > > Peter Eisentraut wrote: > > Tom Lane writes: > > > > > Can't we do both? If the default setup is to put config files in > > > a Postgres-specific directory, then let's make the default arrangement > > > be that that directory is Postgres-owned, mode 700, *and* the config > > > files are Postgres-owned and mode 600. > > > > The problem with this is that the PostgreSQL-specific configuration file > > directory may be used by programs other than the server. E.g., the ODBC > > driver puts stuff in there. In some future life there may be a global > > psqlrc file or the JDBC driver may have a global properties file (don't > > know if that just made sense). So we'd have to make a subdirectory, say > > "server" (or "secure" or "secret" ...). Seems a bit ugly. > > > > Moreover, I don't know if we can make permission changes on directories > > during installation (make install). (Read "can" as: ought to, while > > staying within the vague confines of open-source software build system > > standards.) For all we know, the directory may already be there and the > > installer told us to reuse it. > > > > How is the situation on the broken editors these days? We might just want > > to put a note on the top of each critical file > > > > # Make sure this file is not readable by anyone except you. > > # If you edit it, make sure your editor does not change the permissions on > > # this file. > > # If in doubt, execute chmod go-a filename. > > > > -- > > Peter Eisentraut peter_e@gmx.net > > > > > > -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Did we come to a conclusion on this? > > I had hoped the people that originally demanded this functionality would > comment in this thread. Unless someone can provide a solution that keeps > the data in the configuration files safe without doing anything strange > during installation, the files will stay where they are. OK, is there any value in putting all the files in their own pgsql/etc directory or is the disturbance not worth it? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026