Re: Thoughts on the location of configuration files

From: Daniel Kalchev <daniel(at)digsys(dot)bg>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Thoughts on the location of configuration files
Date: 2001-12-19 08:36:41
Message-ID: 200112190836.KAA01851@dcave.digsys.bg
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>Tom Lane said:
> 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. A person
> slightly more paranoid than myself would argue against exposing any
> part of pg_hba.conf or pg_ident.conf.

Then, count me more paranoid that you.

In a 'serious' database setup, it is unlikely anyone to have 'shell' access to
the database server except 'root' and the DBA (I tend to assume in many places
such separation is valid). This will include larger setups. In these cases
where the config files are is not important at all - perhaps the reason for
the current situation.

In 'lets try it' setups, many people will have access to the files on the
machine and the current setup is fairly secure. However, it will also be
secure enough, if files in /etc are mode 600 (or just not writable/readable by
other) - perhaps PostgreSQL should just refuse to run, if they are not?

The point in hiding pg_hba.conf and pg_ident.conf for example is that an
inexperienced DBA may well make errors in these files that permit unwanted
access - this is much easier to exploit - and no, I don't advocate security
trough obscurity.

Daniel

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Kalchev 2001-12-19 08:40:59 Re: Thoughts on the location of configuration files
Previous Message Daniel Kalchev 2001-12-19 08:23:25 Re: Concerns about this release