Thread: 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
Re: Thoughts on the location of configuration files
From
teg@redhat.com (Trond Eivind Glomsrød)
Date:
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