Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I am confused why we can't just make the directory be owned by
> PostgreSQL super user with 700 permissions, like we do now with /data.

We could do it that way, but then the set of parameters Peter proposed
is quite unreasonable; there should be exactly one, namely the name of
the config directory.

Now that I think about it, that actually seems a pretty reasonable idea.
Just allow all the hand-maintained config files to be placed in a
separate directory, which we treat just like $PGDATA as far as
permissions go.  If you want a backwards-compatible setup, you need only
set the config directory equal to $PGDATA, and you're done.

			regards, tom lane

Thu, 07 Feb 2002 14:49:07 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Summary of new configuration file and data directory locations 
Tom Lane writes:

> Now that I think about it, that actually seems a pretty reasonable idea.
> Just allow all the hand-maintained config files to be placed in a
> separate directory, which we treat just like $PGDATA as far as
> permissions go.  If you want a backwards-compatible setup, you need only
> set the config directory equal to $PGDATA, and you're done.

But that isn't going to satisfy anyone.  The reason that people want this
is so they can mix and match their configuration files between different
servers.  For instance, they might want to share the SSL key files between
all instances.  Or they might want different postgresql.conf files for
each server but put them all into the same directory with different names.
This was a fairly clear request in the original thread.

So the premise is that in theory any file can live anywhere.  And the
access permissions of a file are solely controlled by its own permission
bits and ownership, not what directory it may live in.  Ultimately, the
former way is more secure.

I'm not 100% comfortable either with pg_hba.conf and pg_ident.conf
world-readable by default.  The alternative is to install all
configuration files 0600 by default.  This will work painlessly for
plain-pen installations where everything is owned and run by the same
user.  If the installation and the server instance are owned by separate
users, then the installer will have to issue a few chmod/chown commands,
but he has to do that anyway right now before running initdb.  I imagine
something like this in the installation/setup procedure:

"""
1. Create a user account for the PostgreSQL server. This is the user the
   server will run as. [...]

2. Make sure the user account you created in step 1 can read the
   configuration files.  There are a few ways to make this happen:

   a. Make the configuration files world-readable.  For the SSL
      certificate files and the secondary password files, you should not
      use this method.  For other configuration files, this is safe, but
      if your authentication setup is insecure, everyone will be able to
      see that and exploit it easily.  [Gratuitous comment about security
      through obscurity here]

      $ chmod a+r /usr/local/pgsql/etc/*

   b. Change the ownership of the files to the PostgreSQL user account.

      $ chown postgres /usr/local/pgsql/etc/*

   c. Create a "postgres" group, set the group ownership of the
      configuration files to that group, and make the files group
      readable.

      $ groupadd postgres
      $ usermod -G postgres postgres
      $ chgrp postgres /usr/local/pgsql/etc/*
      $ chmod g+r /usr/local/pgsql/etc/*

      This setup implies that the "postgres" user does not have the
      ability to write to these files, which may be considered desirable
      or annoying.

3. Create a database installation with the "initdb" command.  [Continue as
   usual]
"""

This would give maximum flexibility to a variety of server setups and
paranoia levels.

-- 
Peter Eisentraut   peter_e@gmx.net


Fri, 8 Feb 2002 12:08:37 -0500 (EST)
Peter Eisentraut <peter_e@gmx.net>
Re: Summary of new configuration file and data directory
Peter Eisentraut <peter_e@gmx.net> writes:
> So the premise is that in theory any file can live anywhere.  And the
> access permissions of a file are solely controlled by its own permission
> bits and ownership, not what directory it may live in.  Ultimately, the
> former way is more secure.

<<itch>>  I guess my thoughts on this are colored by bad experience with
tools that are sloppy about preserving ownership/permissions on edited
files.  (I can recall being burnt this way by both Emacs and HP's "SAM"
admin tool.  Perhaps recent versions don't have those bugs anymore.)
I am not at all convinced that "the former way is more secure" in
reality, even if it's cleaner in theory.

Can't we do both?  If the default setup is to put config files in
a Postgres-specific directory, then let's make the default arrangement
be that that directory is Postgres-owned, mode 700, *and* the config
files are Postgres-owned and mode 600.  Anyone who wants to back off
from that is welcome to take responsibility for any security holes
they've created.

> 2. Make sure the user account you created in step 1 can read the
>    configuration files.  There are a few ways to make this happen:

>    a. Make the configuration files world-readable.

I'd prefer you not recommend that at all, and certainly not as the
first alternative.

			regards, tom lane

Fri, 08 Feb 2002 12:28:41 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Summary of new configuration file and data directory locations 
Tom Lane writes:

> Can't we do both?  If the default setup is to put config files in
> a Postgres-specific directory, then let's make the default arrangement
> be that that directory is Postgres-owned, mode 700, *and* the config
> files are Postgres-owned and mode 600.

The problem with this is that the PostgreSQL-specific configuration file
directory may be used by programs other than the server.  E.g., the ODBC
driver puts stuff in there.  In some future life there may be a global
psqlrc file or the JDBC driver may have a global properties file (don't
know if that just made sense).  So we'd have to make a subdirectory, say
"server" (or "secure" or "secret" ...).  Seems a bit ugly.

Moreover, I don't know if we can make permission changes on directories
during installation (make install).  (Read "can" as:  ought to, while
staying within the vague confines of open-source software build system
standards.)  For all we know, the directory may already be there and the
installer told us to reuse it.

How is the situation on the broken editors these days?  We might just want
to put a note on the top of each critical file

# Make sure this file is not readable by anyone except you.
# If you edit it, make sure your editor does not change the permissions on
# this file.
# If in doubt, execute chmod go-a filename.

-- 
Peter Eisentraut   peter_e@gmx.net


Fri, 8 Feb 2002 18:26:54 -0500 (EST)
Peter Eisentraut <peter_e@gmx.net>
Re: Summary of new configuration file and data directory
Peter Eisentraut <peter_e@gmx.net> writes:
> Moreover, I don't know if we can make permission changes on directories
> during installation (make install).  (Read "can" as:  ought to, while
> staying within the vague confines of open-source software build system
> standards.)  For all we know, the directory may already be there and the
> installer told us to reuse it.

Agreed, we should probably not try to change ownership/permission of an
existing directory.  However, if we have to make a directory, it seems
sensible to me to make it Postgres-owned and mode 700.

Your concept of keeping client-side and server-side config files in the
same directory makes me very unhappy; that's a recipe for permission
problems if I ever saw one.

> How is the situation on the broken editors these days?

Well, I'm still using Emacs 19.34, which is a tad old, but it's got a
problem with not preserving file GIDs reliably.  Dunno if this is fixed
in newer releases.

			regards, tom lane

Fri, 08 Feb 2002 18:43:25 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Summary of new configuration file and data directory locations 
Hi guys,

Quick question.  I'm getting the feeling these changes will impact any
company which would like to have one installation of the binaries on
their servers, but which run several instances of these binaries from
the one location.

i.e.

/opt/pgsql/7.2  <-- installed program

/data1  <-- data dir and config files
/data2  <-- data dir and config files
/data3  <-- data dir and config files
<etc>

pg_ctl start -D /data1
pg_ctl start -D /data2
pg_ctl start -D /data3

:-)

Regards and best wishes,

Justin Clift


Tom Lane wrote:
> 
> Peter Eisentraut <peter_e@gmx.net> writes:
> > So the premise is that in theory any file can live anywhere.  And the
> > access permissions of a file are solely controlled by its own permission
> > bits and ownership, not what directory it may live in.  Ultimately, the
> > former way is more secure.
> 
> <<itch>>  I guess my thoughts on this are colored by bad experience with
> tools that are sloppy about preserving ownership/permissions on edited
> files.  (I can recall being burnt this way by both Emacs and HP's "SAM"
> admin tool.  Perhaps recent versions don't have those bugs anymore.)
> I am not at all convinced that "the former way is more secure" in
> reality, even if it's cleaner in theory.
> 
> Can't we do both?  If the default setup is to put config files in
> a Postgres-specific directory, then let's make the default arrangement
> be that that directory is Postgres-owned, mode 700, *and* the config
> files are Postgres-owned and mode 600.  Anyone who wants to back off
> from that is welcome to take responsibility for any security holes
> they've created.
> 
> > 2. Make sure the user account you created in step 1 can read the
> >    configuration files.  There are a few ways to make this happen:
> 
> >    a. Make the configuration files world-readable.
> 
> I'd prefer you not recommend that at all, and certainly not as the
> first alternative.
> 
>                         regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
   - Indira Gandhi

Mon, 11 Feb 2002 11:48:14 +1100
Justin Clift <justin@postgresql.org>
Re: Summary of new configuration file and data directory 

Did we come to a conclusion on this?

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

Peter Eisentraut wrote:
> Tom Lane writes:
> 
> > Can't we do both?  If the default setup is to put config files in
> > a Postgres-specific directory, then let's make the default arrangement
> > be that that directory is Postgres-owned, mode 700, *and* the config
> > files are Postgres-owned and mode 600.
> 
> The problem with this is that the PostgreSQL-specific configuration file
> directory may be used by programs other than the server.  E.g., the ODBC
> driver puts stuff in there.  In some future life there may be a global
> psqlrc file or the JDBC driver may have a global properties file (don't
> know if that just made sense).  So we'd have to make a subdirectory, say
> "server" (or "secure" or "secret" ...).  Seems a bit ugly.
> 
> Moreover, I don't know if we can make permission changes on directories
> during installation (make install).  (Read "can" as:  ought to, while
> staying within the vague confines of open-source software build system
> standards.)  For all we know, the directory may already be there and the
> installer told us to reuse it.
> 
> How is the situation on the broken editors these days?  We might just want
> to put a note on the top of each critical file
> 
> # Make sure this file is not readable by anyone except you.
> # If you edit it, make sure your editor does not change the permissions on
> # this file.
> # If in doubt, execute chmod go-a filename.
> 
> -- 
> Peter Eisentraut   peter_e@gmx.net
> 
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 21 Feb 2002 23:13:21 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Summary of new configuration file and data directory locations
Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> > Did we come to a conclusion on this?
> 
> I had hoped the people that originally demanded this functionality would
> comment in this thread.  Unless someone can provide a solution that keeps
> the data in the configuration files safe without doing anything strange
> during installation, the files will stay where they are.

OK, is there any value in putting all the files in their own pgsql/etc
directory or is the disturbance not worth it?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 22 Feb 2002 00:15:55 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Summary of new configuration file and data directory locations
Bruce Momjian writes:

> Did we come to a conclusion on this?

I had hoped the people that originally demanded this functionality would
comment in this thread.  Unless someone can provide a solution that keeps
the data in the configuration files safe without doing anything strange
during installation, the files will stay where they are.

>
> ---------------------------------------------------------------------------
>
> Peter Eisentraut wrote:
> > Tom Lane writes:
> >
> > > Can't we do both?  If the default setup is to put config files in
> > > a Postgres-specific directory, then let's make the default arrangement
> > > be that that directory is Postgres-owned, mode 700, *and* the config
> > > files are Postgres-owned and mode 600.
> >
> > The problem with this is that the PostgreSQL-specific configuration file
> > directory may be used by programs other than the server.  E.g., the ODBC
> > driver puts stuff in there.  In some future life there may be a global
> > psqlrc file or the JDBC driver may have a global properties file (don't
> > know if that just made sense).  So we'd have to make a subdirectory, say
> > "server" (or "secure" or "secret" ...).  Seems a bit ugly.
> >
> > Moreover, I don't know if we can make permission changes on directories
> > during installation (make install).  (Read "can" as:  ought to, while
> > staying within the vague confines of open-source software build system
> > standards.)  For all we know, the directory may already be there and the
> > installer told us to reuse it.
> >
> > How is the situation on the broken editors these days?  We might just want
> > to put a note on the top of each critical file
> >
> > # Make sure this file is not readable by anyone except you.
> > # If you edit it, make sure your editor does not change the permissions on
> > # this file.
> > # If in doubt, execute chmod go-a filename.
> >
> > --
> > Peter Eisentraut   peter_e@gmx.net
> >
> >
>
>

-- 
Peter Eisentraut   peter_e@gmx.net


Fri, 22 Feb 2002 00:16:00 -0500 (EST)
Peter Eisentraut <peter_e@gmx.net>
Re: Summary of new configuration file and data directory