Обсуждение: Thoughts on the location of configuration files

After reading through the strong opinions about the location of the
configuration files in the current and in previous threads, I must concede
that despite the best intentions, the current "everything in one place"
system is obviously not addressing the needs of the user.  So while we're
at it we might as well consider more sweeping changes to bring the
system in line with the "expected" or "standard" behaviour.

Consider the following points:

1. Most users will probably only run one server -- especially new users.

2. Most users will expect configuration files somewhere under =~ /etc/ --  including new users.

3. To run more than one server, special knowledge and configuration is  required anyway.

Therefore, a wired-in configuration file location near /etc would be
helpful or at least indifferent for most users.

I suggest that we wire-in the location of the configuration files into the
binaries as ${sysconfdir} as determined by configure.  This would default
to /usr/local/pgsql/etc, so the "everything in one place" system is still
somewhat preserved for those that care.  For the confused, we could for a
while install into the data directory files named "postgresql.conf",
"pg_hba.conf", etc. that only contain text like "This file is now to be
found at @sysconfdir@ by popular demand."

Furthermore, I suggest that we wire-in the default location of the data
files as ${localstatedir} as determined by configure.  This would default
to /usr/local/pgsql/var, which is not quite the same as the customary
/usr/local/pgsql/data but it doesn't matter because with both "initdb" and
"postmaster" defaulting to this directory and the configuration files
elsewhere you don't really need to know except on few occasions.  Having
this default would also save me a lot of typing during development. ;-)

Surely we can also add a -C option to override the sysconfdir just as -D
overrides localstatedir.  Those that refuse to convert can also set -C
equal to -D and have the old setup.  Or the user can only specify -C to
point to the former -D and use the proposed 'datadir' parameter to find
the data area.

But I find a wired-in configuration file location better than having to
use -C everytime you want a "standard" setup because this way we force
users to have consistent setups.

What does this mean for multiple-server setups?  Basically you add a -C to
each invocation or you replace -D by -C as explained above.  Or if you
want to share the configuration file you only need to add the right -p
option to each invocation.  This probably means someone will need to
change their scripts but as we hear they don't like them anyway.  Someone
that currently relies on a -D being sufficient will at least get a clean
failure when the ports conflict.

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut wrote:
> 
> After reading through the strong opinions about the location of the
> configuration files in the current and in previous threads, I must concede
> that despite the best intentions, the current "everything in one place"
> system is obviously not addressing the needs of the user.  So while we're
> at it we might as well consider more sweeping changes to bring the
> system in line with the "expected" or "standard" behaviour.
> 
> Consider the following points:
> 
> 1. Most users will probably only run one server -- especially new users.
Agreed
> 
> 2. Most users will expect configuration files somewhere under =~ /etc/ --
>    including new users.
Agreed
> 
> 3. To run more than one server, special knowledge and configuration is
>    required anyway.
Agreed
> 
> Therefore, a wired-in configuration file location near /etc would be
> helpful or at least indifferent for most users.
> 
> I suggest that we wire-in the location of the configuration files into the
> binaries as ${sysconfdir} as determined by configure.  This would default
> to /usr/local/pgsql/etc, so the "everything in one place" system is still
> somewhat preserved for those that care.  For the confused, we could for a
> while install into the data directory files named "postgresql.conf",
> "pg_hba.conf", etc. that only contain text like "This file is now to be
> found at @sysconfdir@ by popular demand."

Great!
> 
> Furthermore, I suggest that we wire-in the default location of the data
> files as ${localstatedir} as determined by configure.  This would default
> to /usr/local/pgsql/var, which is not quite the same as the customary
> /usr/local/pgsql/data but it doesn't matter because with both "initdb" and
> "postmaster" defaulting to this directory and the configuration files
> elsewhere you don't really need to know except on few occasions.  Having
> this default would also save me a lot of typing during development. ;-)

I guess that is OK, but I would also like a setting in the config file for the
datadir location, as well as hba and ident. That way a single "-C" can set the
whole world.

> 
> Surely we can also add a -C option to override the sysconfdir just as -D
> overrides localstatedir.  Those that refuse to convert can also set -C
> equal to -D and have the old setup.  Or the user can only specify -C to
> point to the former -D and use the proposed 'datadir' parameter to find
> the data area.
> 
> But I find a wired-in configuration file location better than having to
> use -C everytime you want a "standard" setup because this way we force
> users to have consistent setups.

However, I wish "-C" to point to a specific file. 

> 
> What does this mean for multiple-server setups?  Basically you add a -C to
> each invocation or you replace -D by -C as explained above.  Or if you
> want to share the configuration file you only need to add the right -p
> option to each invocation.  This probably means someone will need to
> change their scripts but as we hear they don't like them anyway.  Someone
> that currently relies on a -D being sufficient will at least get a clean
> failure when the ports conflict.

Peter Eisentraut <peter_e@gmx.net> writes:
> Therefore, a wired-in configuration file location near /etc would be
> helpful or at least indifferent for most users.

By "wired in" you evidently don't mean hard-wired, but "default
established at configure time with the option to override from the
command line".  That I can live with.  We would presumably also
retire the use of environment variable PGDATA, which strikes
me as a Good Thing.

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.  But I do not think it is safe to assume
that config files living in /etc will reliably be made mode 0600.  Are
there, or might in the future there be, any items in these files that
we'd not want to be world-readable?

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.
        regards, tom lane

Peter Eisentraut wrote:

>After reading through the strong opinions about the location of the
>configuration files in the current and in previous threads, I must concede
>that despite the best intentions, the current "everything in one place"
>system is obviously not addressing the needs of the user.  So while we're
>at it we might as well consider more sweeping changes to bring the
>system in line with the "expected" or "standard" behaviour.
>
>Consider the following points:
>
>1. Most users will probably only run one server -- especially new users.
>
>2. Most users will expect configuration files somewhere under =~ /etc/ --
>   including new users.
>
>3. To run more than one server, special knowledge and configuration is
>   required anyway.
>
>Therefore, a wired-in configuration file location near /etc would be
>helpful or at least indifferent for most users.
>
>I suggest that we wire-in the location of the configuration files into the
>binaries as ${sysconfdir} as determined by configure.  This would default
>to /usr/local/pgsql/etc, so the "everything in one place" system is still
>somewhat preserved for those that care.  For the confused, we could for a
>while install into the data directory files named "postgresql.conf",
>"pg_hba.conf", etc. that only contain text like "This file is now to be
>found at @sysconfdir@ by popular demand."
>
In keeping with some of the more modern daemons (xinetd, etc) you might 
want to consider something like /etc/pgsql.d/ as a directory name.   Where as most folders with a .d contain a set of
filesor a referenced 
 
by the main config file in /etc.  This is on a RedHat system, but I 
think the logic applies well if you are flexible the location of the 
base system config directory.   (/usr/local/etc vs /etc, etc.)

>
>
>Furthermore, I suggest that we wire-in the default location of the data
>files as ${localstatedir} as determined by configure.  This would default
>to /usr/local/pgsql/var, which is not quite the same as the customary
>/usr/local/pgsql/data but it doesn't matter because with both "initdb" and
>"postmaster" defaulting to this directory and the configuration files
>elsewhere you don't really need to know except on few occasions.  Having
>this default would also save me a lot of typing during development. ;-)
>
>Surely we can also add a -C option to override the sysconfdir just as -D
>overrides localstatedir.  Those that refuse to convert can also set -C
>equal to -D and have the old setup.  Or the user can only specify -C to
>point to the former -D and use the proposed 'datadir' parameter to find
>the data area.
>
>But I find a wired-in configuration file location better than having to
>use -C everytime you want a "standard" setup because this way we force
>users to have consistent setups.
>
>What does this mean for multiple-server setups?  Basically you add a -C to
>each invocation or you replace -D by -C as explained above.  Or if you
>want to share the configuration file you only need to add the right -p
>option to each invocation.  This probably means someone will need to
>change their scripts but as we hear they don't like them anyway.  Someone
>that currently relies on a -D being sufficient will at least get a clean
>failure when the ports conflict.
>

>

> >I suggest that we wire-in the location of the configuration files into the
> >binaries as ${sysconfdir} as determined by configure.  This would default
> >to /usr/local/pgsql/etc, so the "everything in one place" system is still
> >somewhat preserved for those that care.  For the confused, we could for a
> >while install into the data directory files named "postgresql.conf",
> >"pg_hba.conf", etc. that only contain text like "This file is now to be
> >found at @sysconfdir@ by popular demand."
> >
> In keeping with some of the more modern daemons (xinetd, etc) you might 
> want to consider something like /etc/pgsql.d/ as a directory name.   
>  Where as most folders with a .d contain a set of files or a referenced 
> by the main config file in /etc.  This is on a RedHat system, but I 
> think the logic applies well if you are flexible the location of the 
> base system config directory.   (/usr/local/etc vs /etc, etc.)

I often wondered, if it is directory, why do they need the '.d' in the
name?  What possible purpose could it have except to look ugly?  :-)

--  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
 

On Tuesday 18 December 2001 05:24 pm, Peter Eisentraut wrote:
> After reading through the strong opinions about the location of the
> configuration files in the current and in previous threads, I must concede
> that despite the best intentions, the current "everything in one place"
> system is obviously not addressing the needs of the user.  So while we're
> at it we might as well consider more sweeping changes to bring the
> system in line with the "expected" or "standard" behaviour.

> Surely we can also add a -C option to override the sysconfdir just as -D
> overrides localstatedir.  Those that refuse to convert can also set -C
> equal to -D and have the old setup.  Or the user can only specify -C to
> point to the former -D and use the proposed 'datadir' parameter to find
> the data area.

While having config files named differently from 'postgresql.conf' would be a 
nice thing, I can live with your proposal without being able to specify 
arbitrary conf file names.  A subdirectory under sysconfdir for each 
'virtual' database would be sufficient.

As to the security points that Tom brings up, you don't put anything in /etc 
directly -- you put it under /etc/pgsql, and lock it down the same as$PGDATA. 
Of course, the logic to do this sort of thing already exists in the configure 
script....  Also on the topic of security, 'encouraging' the use of separate 
subdirs for each server would also provide more isolation for the users of 
those servers.

Oh, and BTW: when this is implemented, the dream of multiple servers running 
under the RPMset install will be realizable... :-)
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:
> As to the security points that Tom brings up, you don't put anything in /etc 
> directly -- you put it under /etc/pgsql, and lock it down the same as$PGDATA.

That'd work if we assume that /etc/pgsql can be owned by the postgres
user.  Is that kosher per the various filesystem layout standards?
Seems to me that someone who thinks the executables should be root-owned
is likely to think the same of the config files.

Personally I think this would be a fine idea, I'm just worried that
we'll find packagers overriding the decision because "the Debian
standards don't allow you to do that" or whatever.
        regards, tom lane

Noting Peter's thought on the matter and merging some of the things I think are
important, I wrote this down as a sort of way of flushing out the precise
meaning of the configuration options:

Command line options:
-C filepath_name
If filepath_name is a file, it is treated as a configuration file, no other
information is assumed. If filepath_file is a directory, it is used to replace
the default "sysconfdir" obtained from configure. 

-D datadir
the -D option overrides any default setting, and any setting in
postgresql.conf.

Other options
All other options override the defaults set by either the "configure" operation
or the active postgresql.conf file.

postgresql.conf
By default it will live in sysconfdir as configured by "configure." 
If it is not found in the "sysconfdir," $PGDATA will be searched.
Using the "-C" option forces the file's explicit location. If "-C" is
specified, postgresql.conf (or filename) must exist as specified in accordance
with the documented "-C" behavior.
It may contain a setting "hbaconfig" which will override the default location.
It may contain a setting "identconfig" which will override the default
location.
It may contain a setting "datadir" which will override the default location.

pg_hba.conf
By default it will live in sysconfdir as configured by "configure."
Its location can be changed by "hbaconfig" in postgresql.conf.
If not configured in postgresql.conf and not found within "sysconfdir," $PGDATA
will be searched. If explicitly configured in the postgresql.conf file, it must
exist as specified.

pg_ident.conf
By default it will live in sysconfdir as configured by "configure."
Its location can be changed by "identconfig" in postgresql.conf.
If not configured in postgresql.conf and not found within "sysconfdir," $PGDATA
will be searched. If explicitly configured in the postgresql.conf file, it must
exist as specified.

PGDATA
The data directory will be found in the directory configured by GNU "configure"
If the environment variable PGDATA is specified, it overrides the configured
default.
If the postgresql.conf file contains "datadir" it overrides the previous other
two.
If the command line "-D" option is used, it overrides the previous three.


Note:
I think the data directory should be explicitly configured by either the
posgresql.conf file, environment variable (PGDATA), or through the command line
option, but using the "configure" statedir isn't anything anyone would object
too.


What do you all think? 
Is anything ambiguous?
Is anything wrong?
Can we all agree this is how it should be?

On Tuesday 18 December 2001 11:50 pm, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > As to the security points that Tom brings up, you don't put anything in
> > /etc directly -- you put it under /etc/pgsql, and lock it down the same
> > as$PGDATA.

> That'd work if we assume that /etc/pgsql can be owned by the postgres
> user.  Is that kosher per the various filesystem layout standards?

The Red-Hat-issue 'ntp' package has a /etc/ntp that is owned by ntp.ntp.  So 
there's at least precedence.  I'll have to peruse the FHS to see if it's 
parve or not.  Cursory reading indicates that it is not specified as to 
ownership in /etc.  The LSB may state something else -- I'll look at it 
later, unless someone else wants to beat me to it... :-)

However, that same standard states, about /var/lib (under which PGDATA lives, 
as the database itself is 'state information'), that users must never need to 
modify files here for configuration of program operation.  IE, the current 
RPM packages are not FHS-2.2 compliant, as postgresql.conf is under /var/lib. 
:-(

This config file change would allow compliance much more easily.

> Seems to me that someone who thinks the executables should be root-owned
> is likely to think the same of the config files.

Sorry to disappoint you :-).  No, I envision a tree where you could have:
/etc/pgsql
drwx------    1 pari           pari               4096 Nov  9 01:16 pari
drwx------    1 postgres    postgres         4096 Nov  9 01:11 main-web
drwx------    1 nobody      nobody           4096 May 15  2000 devel
drwxrwx---    1 lowen        wgcr             4096 Nov  9 22:37 wgcr

Or some such.  And the existing config files are postgres.postgres owned, 
under /var/lib/pgsql (the whole tree is postgres owned). To match the 
/etc/pgsql tree, I'd do the same in /var/lib/pgsql, with the default location 
being 'data' in order to be backward-compatible.

However, IMHO, for best security, the executables do need to be root owned.  
IMHO.  Even though none of our executables runs as root or is suid root, it 
is just a good practice to not have network-accessible executables being able 
to overwrite themselves under buffer overflow conditions.  This is procedure 
de rigeur for webservers -- at least one set of the AOLserver docs 
specifically recommends it. Of course, a webserver requires running as root 
to bind TCP port 80, but the principle is, IMHO, still valid for non-root 
unprivileged-port-binding daemons -- they shouldn't be able to scribble on 
top of themselves.

> Personally I think this would be a fine idea, I'm just worried that
> we'll find packagers overriding the decision because "the Debian
> standards don't allow you to do that" or whatever.

Oliver?  My gut feel is that Oliver would jump for joy over this proposal.  
But Oliver should answer for himself.

Red Hat doesn't have an external packaging standards document; what I've 
found I've found through the FHS, the Mandrake RPM HOWTO, and trial and error 
(the trials of error?).  Trond, Jeff Johnson, Cristian Gafton, and lots of 
actual users of my packages have taught me much more than any document has. 
:-)  Some lessons are more 'memorable' than others.....

Or, more bluntly, I don't plan on 'overriding' this -- nay, this thing would 
suit me _just_fine_. Too bad this is a post-7.2 thing.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

> Lamar Owen <lamar.owen@wgcr.org> writes:
> > As to the security points that Tom brings up, you don't put anything in /etc 
> > directly -- you put it under /etc/pgsql, and lock it down the same as$PGDATA.
> 
> That'd work if we assume that /etc/pgsql can be owned by the postgres
> user.  Is that kosher per the various filesystem layout standards?
> Seems to me that someone who thinks the executables should be root-owned
> is likely to think the same of the config files.
> 
> Personally I think this would be a fine idea, I'm just worried that
> we'll find packagers overriding the decision because "the Debian
> standards don't allow you to do that" or whatever.

Seems the proper default location is /usr/local/pgsql/config.  Anything
else and non-root people have trouble with the install.

--  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 <pgman@candle.pha.pa.us> writes:
> Seems the proper default location is /usr/local/pgsql/config.  Anything
> else and non-root people have trouble with the install.

I think it'd be reasonable for the source distribution to be set up
to default to that, but the RPMs need not, since they're not intended
to be installed non-root.
        regards, tom lane

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Seems the proper default location is /usr/local/pgsql/config.  Anything
> > else and non-root people have trouble with the install.
> 
> I think it'd be reasonable for the source distribution to be set up
> to default to that, but the RPMs need not, since they're not intended
> to be installed non-root.

Yes, I thought we were just talking about our source default.

--  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
 

Lamar Owen <lamar.owen@wgcr.org> writes:
>> Seems to me that someone who thinks the executables should be root-owned
>> is likely to think the same of the config files.

> Sorry to disappoint you :-).
> ...
> However, IMHO, for best security, the executables do need to be root owned.  

Or at least not owned/writable by the postgres user.  Sure, that seems
like a good idea for a high-security installation.  But I always thought
the motivation for that rule was to prevent someone who'd gained some
control of the program (eg via a buffer-overrun exploit) from expanding
his exploit by overwriting the executables with malicious code.  If the
config files can be overwritten by the postgres user, then you still
have an avenue for an attacker to expand his privileges.  Example: he
can trivially become postgres superuser after altering pg_hba.conf.
        regards, tom lane

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Seems the proper default location is /usr/local/pgsql/config.  Anything
> > else and non-root people have trouble with the install.
> 
> I think it'd be reasonable for the source distribution to be set up
> to default to that, but the RPMs need not, since they're not intended
> to be installed non-root.

Let me add I think a separate /config directory is a good idea rather
than putting it in /data because when you do pg_dump, you don't need a
file system backup of '/data, except that you do need to backup those
config files because they are not part of the contents of pg_dump.  I
had to mention that particularly in my book, and it was kind of awkward.

--  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
 

On Wednesday 19 December 2001 01:09 am, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> >> Seems to me that someone who thinks the executables should be root-owned
> >> is likely to think the same of the config files.

> > Sorry to disappoint you :-)....
> > However, IMHO, for best security, the executables do need to be root
> > owned.

> his exploit by overwriting the executables with malicious code.  If the
> config files can be overwritten by the postgres user, then you still
> have an avenue for an attacker to expand his privileges.  Example: he
> can trivially become postgres superuser after altering pg_hba.conf.

This much is true.  Hmmm. More thought required.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Wednesday 19 December 2001 12:47 am, Bruce Momjian wrote:
> > Lamar Owen <lamar.owen@wgcr.org> writes:
> > > As to the security points that Tom brings up, you don't put anything in
> > > /etc directly -- you put it under /etc/pgsql, and lock it down the same
> > > as$PGDATA.

> > That'd work if we assume that /etc/pgsql can be owned by the postgres

> > Personally I think this would be a fine idea, I'm just worried that
> > we'll find packagers overriding the decision because "the Debian
> > standards don't allow you to do that" or whatever.

> Seems the proper default location is /usr/local/pgsql/config.  Anything
> else and non-root people have trouble with the install.

Oh, I'm not talking _default_ -- I'm talking 'optional and allowed'.  IMHO, 
default should be /usr/local/pgsql/etc. This is sysconfdir under configure in 
the default case, right? That's Peter's proposal -- use sysconfdir for its 
intended purpose in all installs.  Of course, sysconfdir varies -- but then a 
'pg_config --configure' gives you where things are by default..... Although I 
didn't know about 'statedir' being PREFIX/var by default.  Nice one to know.

Could pg_config possibly be endowed with another option -- while listing the 
options given to configure is nice, it would be nicer to list all the options 
configure had, including the defaults, in a slightly more useful form?
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

>>>Tom Lane said:> Secondary password files are a fairly obvious example of stuff better> not left out in the cold.  We
couldprobably deprecate the practice> of keeping any actual passwords in such files ;-) ... but I wonder> whether it'd
notbe 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

>>>Thomas Swan said:> In keeping with some of the more modern daemons (xinetd, etc) you might > want to consider
somethinglike /etc/pgsql.d/ as a directory name.   >  Where as most folders with a .d contain a set of files or a
referenced> by the main config file in /etc.  This is on a RedHat system, but I > think the logic applies well if you
areflexible the location of the > base system config directory.   (/usr/local/etc vs /etc, etc.)
 

I run BSD, and I believe config files should sit in /etc if the files are not 
many. We can even go with one config file, such as postgres.conf which will 
include the paths to other files - that can sit anywhere - in /etc/pgsql for 
example or in /usr/local/pgsql/etc.

But, let's not start religious wars whether the System V way is better than 
BSD's :-)

Daniel

> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] 
> Sent: 19 December 2001 02:07
> To: Thomas Swan
> Cc: Peter Eisentraut; PostgreSQL Development
> Subject: Re: Thoughts on the location of configuration files
> 
> 
> > >I suggest that we wire-in the location of the configuration files 
> > >into the binaries as ${sysconfdir} as determined by 
> configure.  This 
> > >would default to /usr/local/pgsql/etc, so the "everything in one 
> > >place" system is still somewhat preserved for those that 
> care.  For 
> > >the confused, we could for a while install into the data directory 
> > >files named "postgresql.conf", "pg_hba.conf", etc. that 
> only contain 
> > >text like "This file is now to be found at @sysconfdir@ by popular 
> > >demand."
> > >
> > In keeping with some of the more modern daemons (xinetd, 
> etc) you might 
> > want to consider something like /etc/pgsql.d/ as a 
> directory name.   
> >  Where as most folders with a .d contain a set of files or a 
> > referenced
> > by the main config file in /etc.  This is on a RedHat system, but I 
> > think the logic applies well if you are flexible the 
> location of the 
> > base system config directory.   (/usr/local/etc vs /etc, etc.)
> 
> I often wondered, if it is directory, why do they need the 
> '.d' in the name?  What possible purpose could it have except 
> to look ugly?  :-)

Isn't this a RedHat thing anyway? Precisely why I use Slackware...

Regards, Dave.

Tom Lane wrote:
> 
> Lamar Owen <lamar.owen@wgcr.org> writes:
> >> Seems to me that someone who thinks the executables should be root-owned
> >> is likely to think the same of the config files.
> 
> > Sorry to disappoint you :-).
> > ...
> > However, IMHO, for best security, the executables do need to be root owned.
> 
> Or at least not owned/writable by the postgres user.  Sure, that seems
> like a good idea for a high-security installation.  But I always thought
> the motivation for that rule was to prevent someone who'd gained some
> control of the program (eg via a buffer-overrun exploit) from expanding
> his exploit by overwriting the executables with malicious code.  If the
> config files can be overwritten by the postgres user, then you still
> have an avenue for an attacker to expand his privileges.  Example: he
> can trivially become postgres superuser after altering pg_hba.conf.

One of the nice features of putting configuration files in /etc
instead of /var is that some people like to mount the root
filesystem (non-/var directories) read-only on a disc that is
physically jumpered read-only, or some other read-only media. Its an
attempt to prevent buffer exploits from modifying executables and
configuration files, even if root is achieved. Of course, it
wouldn't stop someone with destroying anything in /var, but it at
least limits the potential damage in some meaningful way.

Mike Mascari
mascarm@mascari.com

Dave Page wrote:<br /><br /> *snip*<br /><blockquote
cite="mid:FED2B709E3270E4B903EB0175A49BCB1047390@dogbert.vale-housing.co.uk"type="cite"><blockquote
type="cite"><blockquotetype="cite"><pre wrap="">In keeping with some of the more modern daemons (xinetd,etc) you might
wantto consider something like /etc/pgsql.d/ as a directory name.   Where as most folders with a .d contain a set of
filesor a <br />referenced by the main config file in /etc.  This is on a RedHat system, but I <br />think the logic
applieswell if you are flexible the location of the base system config directory.   (/usr/local/etc vs /etc, etc.)<br
/></pre></blockquote><prewrap="">I often wondered, if it is directory, why do they need the <br />'.d' in the name?
Whatpossible purpose could it have except <br />to look ugly?  :-)<br /></pre></blockquote><pre wrap=""><br />Isn't
thisa RedHat thing anyway? Precisely why I use Slackware...</pre></blockquote> Perhaps... I just thought I'd mention it
asan observation.   Regardless, being able to locate the config outside of the database directory is a Good Thing (tm).
 I'mreally in favor of the /etc/postgresql.conf and support files being put in /etc/pgsql/ or some other system config
dir,--with-sysconfdir={something}as specified at compile time...<br /><blockquote>@sysconfdir@ = /etc ...<br />
postgresql.confin @sysconfdir@ <br /> support files in @sysconfdir@/pgsql or someother place specified in
postgresql.conf<br/><br /></blockquote> 

mlw writes:

> -C filepath_name
> If filepath_name is a file, it is treated as a configuration file, no other
> information is assumed. If filepath_file is a directory, it is used to replace
> the default "sysconfdir" obtained from configure.

This seems like a reasonable compromise, but I think I'm OK with -C
specifying the name of the config file only.  Otherwise it would be too
much logic for something that you can work around with tab completion.

> postgresql.conf
> By default it will live in sysconfdir as configured by "configure."
> If it is not found in the "sysconfdir," $PGDATA will be searched.

I don't think I like "if not found in X then search Y".  If the file is
not where it was configured to be then it's an error or it will be
ignored, or whatever the usual behavior would be.

Looking into $PGDATA is probably something we want to discourage, not do
implicitly.  The backup/upgrade issue would be much simplified if we kept
hand-edited files out of there.  Are you concerned about backward
compatibility?  I think a note in the data directory that tells users
where to find the files is OK.  Others may disagree.

Also, I'm not sure exactly what you mean with $PGDATA.  If you mean "the
data area", then this would be complicated to arrange, because the data
area is or may be configured in postgresql.conf.  If you mean the actual
environment variable, I think environment variables should override
compiled-in defaults, not serve as fallbacks.  That's just the usual order
of priorities.

> pg_hba.conf
> By default it will live in sysconfdir as configured by "configure."
> Its location can be changed by "hbaconfig" in postgresql.conf.
> If not configured in postgresql.conf and not found within "sysconfdir," $PGDATA
> will be searched. If explicitly configured in the postgresql.conf file, it must
> exist as specified.

Same concern here.

> Note:
> I think the data directory should be explicitly configured by either the
> posgresql.conf file, environment variable (PGDATA), or through the command line
> option, but using the "configure" statedir isn't anything anyone would object
> too.

Fixed locations create consistency and save typing.  Both are tremendous
time-savers.

-- 
Peter Eisentraut   peter_e@gmx.net

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@gmx.net

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I have an idea for the Unix socket file permissions and local 'trust'
> permissoins as default.  Right now we allow the socket permissions to be
> set in postgresql.conf, but that seems like the wrong place for it.

> Suppose we add an option to pg_hba.conf for 'local' connections called
> 'singleuser' and 'singlegroup' which set enable socket permissions
> only for the postgres super-user or his group.

That strikes me as (a) not better, and (b) not backwards compatible.
What's the point?
        regards, tom lane

> 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.

I have an idea for the Unix socket file permissions and local 'trust'
permissoins as default.  Right now we allow the socket permissions to be
set in postgresql.conf, but that seems like the wrong place for it.

Suppose we add an option to pg_hba.conf for 'local' connections called
'singleuser' and 'singlegroup' which set enable socket permissions only for the
postgres super-user or his group.

That way, we can ship the default pg_hba.conf file default as
'singleuser' and allow people to change it as they wish.

If people think this is a good idea, I will add it to the TODO list.

--  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 <pgman@candle.pha.pa.us> writes:
> > I have an idea for the Unix socket file permissions and local 'trust'
> > permissoins as default.  Right now we allow the socket permissions to be
> > set in postgresql.conf, but that seems like the wrong place for it.
> 
> > Suppose we add an option to pg_hba.conf for 'local' connections called
> > 'singleuser' and 'singlegroup' which set enable socket permissions
> > only for the postgres super-user or his group.
> 
> That strikes me as (a) not better, and (b) not backwards compatible.
> What's the point?

Well, the problem with backward compatibility here is that now we have
pg_hba.conf to configure some part of local authentication and
postgresql.conf to configure the other part.  Seems quite confusing to
me.  If you would prefer, we could allow specification of the socket
permissions in pg_hba.conf.

Aren't the socket permissions best dealt with in pg_hba.conf?

--  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 <pgman@candle.pha.pa.us> writes:
> Well, the problem with backward compatibility here is that now we have
> pg_hba.conf to configure some part of local authentication and
> postgresql.conf to configure the other part.

Seems a pretty empty argument.  pg_ident.conf also (now) bears on local
authentication, as does any random secondary-password file the user
might select.  Shall we find a way to smush all that into pg_hba.conf?

> Aren't the socket permissions best dealt with in pg_hba.conf?

Maybe if we were designing the whole thing from scratch, it'd be cleaner
to do it that way ... but it doesn't seem enough cleaner to justify
creating a compatibility issue.
        regards, tom lane

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Well, the problem with backward compatibility here is that now we have
> > pg_hba.conf to configure some part of local authentication and
> > postgresql.conf to configure the other part.
> 
> Seems a pretty empty argument.  pg_ident.conf also (now) bears on local
> authentication, as does any random secondary-password file the user
> might select.  Shall we find a way to smush all that into pg_hba.conf?
> 
> > Aren't the socket permissions best dealt with in pg_hba.conf?
> 
> Maybe if we were designing the whole thing from scratch, it'd be cleaner
> to do it that way ... but it doesn't seem enough cleaner to justify
> creating a compatibility issue.

How many people really use unix socket permissions in postgresql.conf?
Probably very few.  We could announce when it goes away, and even throw
an error if it appears in postgresql.conf.  Seems that would clear it up
and make the feature much more usable.

Security is very easy to mess up.  That's why I think clarity is
important.  If we are going to change the default socket permissions to
700, that clearly would be a good time to make the change, no?

--  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
 

> How many people really use unix socket permissions in postgresql.conf?
> Probably very few.  We could announce when it goes away, and even throw
> an error if it appears in postgresql.conf.  Seems that would clear it up
> and make the feature much more usable.
> 
> Security is very easy to mess up.  That's why I think clarity is
> important.  If we are going to change the default socket permissions to
> 700, that clearly would be a good time to make the change, no?

Now that I look at postgresql.conf, I do see lots of connection-related
stuff:##       Connection Parameters##tcpip_socket = false#ssl = false#max_connections = 32#port = 5432
#hostname_lookup= false#show_source_port = false#unix_socket_directory = ''#unix_socket_group =
''#unix_socket_permissions= 0777#virtual_host = ''#krb_server_keyfile = ''
 

I guess my problem is that we will have 'trust' in pg_hba.conf, but then
override that in postgresql.conf by restricting permissions to one user.
That seems kind of strange.  We may have to change pg_hba.conf 'trust'
anyway to something like 'socketpermit', or remove the permission
setting in postgresql.conf and add the two new ones I suggested,
singleuser, and singlegroup.

--  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
 

I still don't think you've presented any argument that justifies
breaking existing config files ... but I'll shut up now and wait
to see what others think.
        regards, tom lane

Lamar Owen writes:

> Why isn't all of it in postgresql.conf?

Because the postgresql.conf and pg_hba.conf files describe different data
structures that are evaluated at different times in different ways for
different reasons.

-- 
Peter Eisentraut   peter_e@gmx.net

Bruce Momjian writes:

> I have an idea for the Unix socket file permissions and local 'trust'
> permissoins as default.  Right now we allow the socket permissions to be
> set in postgresql.conf, but that seems like the wrong place for it.
>
> Suppose we add an option to pg_hba.conf for 'local' connections called
> 'singleuser' and 'singlegroup' which set enable socket permissions only for the
> postgres super-user or his group.

This is neither necessarily better, nor even possible.

The pg_hba.conf file describes a set (or list) of rules whose input values
are certain known parameters from the connection request and whose output
value is an authentication method.  The permissions of the socket operate
on a completely different level: they are considered before a connection
request is even generated from the postmaster's point of view, and they
don't describe any part of any rule that evaluates to an authentication
method, instead they are a scalar state variable of the server.

You can have more than one 'local' record, but you can have only one set
of permissions for the socket, so it wouldn't work in general cases.
Moreover, attaching the permissions to each record gives users a view of
the world which really isn't there, which is quite worse, considering that
it's a security-related issue.

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

> Therefore, a wired-in configuration file location near /etc would be
> helpful or at least indifferent for most users.
> 
> I suggest that we wire-in the location of the configuration files into the
> binaries as ${sysconfdir} as determined by configure.  This would default
> to /usr/local/pgsql/etc, so the "everything in one place" system is still
> somewhat preserved for those that care.  For the confused, we could for a
> while install into the data directory files named "postgresql.conf",
> "pg_hba.conf", etc. that only contain text like "This file is now to be
> found at @sysconfdir@ by popular demand."
> 
> Furthermore, I suggest that we wire-in the default location of the data
> files as ${localstatedir} as determined by configure.  This would default
> to /usr/local/pgsql/var, which is not quite the same as the customary
> /usr/local/pgsql/data but it doesn't matter because with both "initdb" and
> "postmaster" defaulting to this directory and the configuration files
> elsewhere you don't really need to know except on few occasions.  Having
> this default would also save me a lot of typing during development. ;-)
> 
> Surely we can also add a -C option to override the sysconfdir just as -D
> overrides localstatedir.  Those that refuse to convert can also set -C
> equal to -D and have the old setup.  Or the user can only specify -C to
> point to the former -D and use the proposed 'datadir' parameter to find
> the data area.

I like this, but I'd prefer to have "-C" point to a specific
configuration file.


-- 
Trond Eivind Glomsrød
Red Hat, Inc.

[ Charset ISO-8859-1 unsupported, converting... ]
> Peter Eisentraut <peter_e@gmx.net> writes:
> 
> > Therefore, a wired-in configuration file location near /etc would be
> > helpful or at least indifferent for most users.
> > 
> > I suggest that we wire-in the location of the configuration files into the
> > binaries as ${sysconfdir} as determined by configure.  This would default
> > to /usr/local/pgsql/etc, so the "everything in one place" system is still
> > somewhat preserved for those that care.  For the confused, we could for a
> > while install into the data directory files named "postgresql.conf",
> > "pg_hba.conf", etc. that only contain text like "This file is now to be
> > found at @sysconfdir@ by popular demand."
> > 
> > Furthermore, I suggest that we wire-in the default location of the data
> > files as ${localstatedir} as determined by configure.  This would default
> > to /usr/local/pgsql/var, which is not quite the same as the customary
> > /usr/local/pgsql/data but it doesn't matter because with both "initdb" and
> > "postmaster" defaulting to this directory and the configuration files
> > elsewhere you don't really need to know except on few occasions.  Having
> > this default would also save me a lot of typing during development. ;-)
> > 
> > Surely we can also add a -C option to override the sysconfdir just as -D
> > overrides localstatedir.  Those that refuse to convert can also set -C
> > equal to -D and have the old setup.  Or the user can only specify -C to
> > point to the former -D and use the proposed 'datadir' parameter to find
> > the data area.
> 
> I like this, but I'd prefer to have "-C" point to a specific
> configuration file.

I understand the value of pointing to a specific configuration file, but
we then would need to define the location of pg_hba.conf and others in
that file, and it makes it hard to move that directory anywhere because
the file paths have to be updated in the file.  Of course, we could
default to look in the same directory as the config file, but that seems
quite confusing.  Seems easier to just point to a directory and find all
the stuff in there you want.

This does allow you to share postgresql.conf, pg_hba.conf, and
pg_ident.conf with multiple servers if you override the port on
postmaster startup for each server.  What it doesn't allow you to do is
share only pg_hba.conf.  For that, you have to set up multiple
directories and symlink the pg_hba.conf's together.

--  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
 

Please forget what I said here.  I see this thread was continued later
and a compromise was reached.

---------------------------------------------------------------------------

> > > Surely we can also add a -C option to override the sysconfdir just as -D
> > > overrides localstatedir.  Those that refuse to convert can also set -C
> > > equal to -D and have the old setup.  Or the user can only specify -C to
> > > point to the former -D and use the proposed 'datadir' parameter to find
> > > the data area.
> > 
> > I like this, but I'd prefer to have "-C" point to a specific
> > configuration file.
> 
> I understand the value of pointing to a specific configuration file, but
> we then would need to define the location of pg_hba.conf and others in
> that file, and it makes it hard to move that directory anywhere because
> the file paths have to be updated in the file.  Of course, we could
> default to look in the same directory as the config file, but that seems
> quite confusing.  Seems easier to just point to a directory and find all
> the stuff in there you want.
> 
> This does allow you to share postgresql.conf, pg_hba.conf, and
> pg_ident.conf with multiple servers if you override the port on
> postmaster startup for each server.  What it doesn't allow you to do is
> share only pg_hba.conf.  For that, you have to set up multiple
> directories and symlink the pg_hba.conf's together.

--  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