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.
Show quoted text
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 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.)
Show quoted text
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, Pennsylvania 19026
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
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?
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
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, Pennsylvania 19026Bruce 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, Pennsylvania 19026Bruce 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 19026Lamar 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
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 could probably deprecate the practice
of keeping any actual passwords in such files ;-) ... but I wonder
whether it'd not be better to leave them under $PGDATA. A person
slightly more paranoid than myself would argue against exposing any
part of pg_hba.conf or pg_ident.conf.
Then, count me more paranoid that you.
In a 'serious' database setup, it is unlikely anyone to have 'shell' access to
the database server except 'root' and the DBA (I tend to assume in many places
such separation is valid). This will include larger setups. In these cases
where the config files are is not important at all - perhaps the reason for
the current situation.
In 'lets try it' setups, many people will have access to the files on the
machine and the current setup is fairly secure. However, it will also be
secure enough, if files in /etc are mode 600 (or just not writable/readable by
other) - perhaps PostgreSQL should just refuse to run, if they are not?
The point in hiding pg_hba.conf and pg_ident.conf for example is that an
inexperienced DBA may well make errors in these files that permit unwanted
access - this is much easier to exploit - and no, I don't advocate security
trough obscurity.
Daniel
Thomas Swan said:
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 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 filesI suggest that we wire-in the location of the configuration files
into the binaries as ${sysconfdir} as determined byconfigure. This
would default to /usr/local/pgsql/etc, so the "everything in one
place" system is still somewhat preserved for those thatcare. For
the confused, we could for a while install into the data directory
files named "postgresql.conf", "pg_hba.conf", etc. thatonly 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 thelocation 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.
Import Notes
Resolved by subject fallback
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
