Thread

1. Thoughts on the location of configuration files

   Peter Eisentraut <peter_e@gmx.net> — 2001-12-18T22:24:43Z

   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
   
   
   

2. Re: Thoughts on the location of configuration files

   mlw <markw@mohawksoft.com> — 2001-12-18T23:31:32Z

   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.
   
   

3. Re: Thoughts on the location of configuration files

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-12-18T23:42:45Z

   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
   
   

4. Re: Thoughts on the location of configuration files

   Thomas Swan <tswan-lst@ics.olemiss.edu> — 2001-12-19T00:04:49Z

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

5. Re: Thoughts on the location of configuration files

   Bruce Momjian <pgman@candle.pha.pa.us> — 2001-12-19T02:06:31Z

   > >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, Pennsylvania 19026
   
   

6. Re: Thoughts on the location of configuration files

   Lamar Owen <lamar.owen@wgcr.org> — 2001-12-19T03:47:18Z

   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
   
   

7. Re: Thoughts on the location of configuration files, how about this:

   mlw <markw@mohawksoft.com> — 2001-12-19T04:48:32Z

   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?
   
   

8. Re: Thoughts on the location of configuration files

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-12-19T04:50:40Z

   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
   
   

9. Re: Thoughts on the location of configuration files

   Lamar Owen <lamar.owen@wgcr.org> — 2001-12-19T05:42:45Z

   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
   
   

10. Re: Thoughts on the location of configuration files

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-12-19T05:47:41Z

    > 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, Pennsylvania 19026
    
    

11. Re: Thoughts on the location of configuration files

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-12-19T05:57:23Z

    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
    
    

12. Re: Thoughts on the location of configuration files

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-12-19T06:05:34Z

    > 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, Pennsylvania 19026
    
    

13. Re: Thoughts on the location of configuration files

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-12-19T06:07:45Z

    > 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, Pennsylvania 19026
    
    

14. Re: Thoughts on the location of configuration files

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-12-19T06:09:15Z

    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
    
    

15. Re: Thoughts on the location of configuration files

    Lamar Owen <lamar.owen@wgcr.org> — 2001-12-19T06:13:29Z

    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
    
    

16. Re: Thoughts on the location of configuration files

    Lamar Owen <lamar.owen@wgcr.org> — 2001-12-19T06:23:34Z

    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
    
    

17. Re: Thoughts on the location of configuration files

    Mike Mascari <mascarm@mascari.com> — 2001-12-19T09:16:56Z

    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
    
    

18. Re: Thoughts on the location of configuration files, how about this:

    Peter Eisentraut <peter_e@gmx.net> — 2001-12-20T17:12:55Z

    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
    
    
    

19. Re: Thoughts on the location of configuration files

    Peter Eisentraut <peter_e@gmx.net> — 2001-12-20T17:13:30Z

    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
    
    
    

20. Re: Thoughts on the location of configuration files

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-12-24T03:27:13Z

    > 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, Pennsylvania 19026
    
    

21. Re: Thoughts on the location of configuration files

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-12-24T03:31:56Z

    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
    
    

22. Re: Thoughts on the location of configuration files

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-12-24T03:35:58Z

    > 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, Pennsylvania 19026
    
    

23. Re: Thoughts on the location of configuration files

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-12-24T03:43:59Z

    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
    
    

24. Re: Thoughts on the location of configuration files

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-12-24T03:49:38Z

    > 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, Pennsylvania 19026
    
    

25. Re: Thoughts on the location of configuration files

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-12-24T04:39:47Z

    > 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, Pennsylvania 19026
    
    

26. Re: Thoughts on the location of configuration files

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-12-24T04:56:16Z

    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
    
    

27. Re: Thoughts on the location of configuration files

    Peter Eisentraut <peter_e@gmx.net> — 2001-12-25T20:29:25Z

    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
    
    
    

28. Re: Thoughts on the location of configuration files

    Trond Eivind Glomsrød <teg@redhat.com> — 2001-12-26T14:51:04Z

    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.
    
    

29. Re: Thoughts on the location of configuration files

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-12-30T02:38:44Z

    [ 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, Pennsylvania 19026
    
    

30. Re: Thoughts on the location of configuration files

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-12-30T03:20:44Z

    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, Pennsylvania 19026