Re: Thoughts on the location of configuration files

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Thoughts on the location of configuration files
Date: 2001-12-20 17:13:30
Message-ID: Pine.LNX.4.30.0112201707280.634-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane writes:

> One thing we should think about before becoming too enthusiastic is
> security considerations. Up to now, we have not really thought hard
> about whether there are any items in the configuration files that
> shouldn't be visible to random users, because all of them live under
> $PGDATA and the directory protection on $PGDATA renders all the config
> files secure from prying eyes.

The important thing is that we give users the option of setting it up in
which ever way they like.

Personally, I would make the configuration files 0644 by default.
There's nothing in there that you can't get at in another way or which
would matter to outsiders. I hope in the next release we make the
unix_socket_permissions default to 0700 so the default setup is totally
secure even if you messed up your pg_hba.conf.

If people don't feel like exposing their pg_hba.conf setup to the world,
then let them change the permissions. There are several useful ways,
including the old owned-by-postgres, or root ownership and a 'postgres'
group that can read the file for the sophisticated. Put a comment at the
top of the file reminding the user to think about it, and we should be as
safe as it can get.

> Secondary password files are a fairly obvious example of stuff better
> not left out in the cold. We could probably deprecate the practice
> of keeping any actual passwords in such files ;-) ... but I wonder
> whether it'd not be better to leave them under $PGDATA.

If you put actual passwords in those files then you should think about
making the file not readable by anyone but the server. The most we can
reasonably do there is to put a clear reminder somewhere. But password
files are traditionally kept with config files, so I think it's okay.
Also, keeping *all* hand-edited files out of the data directory would
simplify the backup and upgrade process.

--
Peter Eisentraut peter_e(at)gmx(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Kalchev 2001-12-20 17:29:35 Re: tkConfig.sh vs. ./configure
Previous Message Peter Eisentraut 2001-12-20 17:13:12 Re: tkConfig.sh vs. ./configure