Thread: Re: [HACKERS] Is "trust" really a good default?
>The only part of this discussion that I'd really be prepared >to buy into >is the part about *if* you use -W or --pwfile, then set up pg_hba.conf >with MD5 as the default auth (because that's probably what the user >wants anyway). But otherwise I think we should leave initdb's behavior >alone. I do not agree with trying to force people to use passwords. Ok. Here is a patch that does this. I still think there should be a warning when trust is set, but I'm clearly not convincing enough about this. Might still be worth adding "--ident" as a parameter anyway, but in that case only to help the distros that need it. Or not, because they already have a way to deal with it. //Magnus
Attachment
Magnus Hagander wrote:
> >The only part of this discussion that I'd really be prepared
> >to buy into
> >is the part about *if* you use -W or --pwfile, then set up pg_hba.conf
> >with MD5 as the default auth (because that's probably what the user
> >wants anyway). But otherwise I think we should leave initdb's behavior
> >alone. I do not agree with trying to force people to use passwords.
>
>
> Ok. Here is a patch that does this. I still think there should be a
> warning when trust is set, but I'm clearly not convincing enough about
> this.
I think there should be a warning. The warning will not be 100%
effective, but I see no reason _not_ to give a warning. This is an
ease-of-user issues which are usuaully not 100% but can be very helpful.
> Might still be worth adding "--ident" as a parameter anyway, but in that
> case only to help the distros that need it. Or not, because they already
> have a way to deal with it.
I think --ident would be very helpful, and we know with OS's support
ident too. Actually looking at the code, we need some way to define
this so initdb would know if ident was a reasonable value for this OS:
errmsg("Ident authentication is not supported on local connections on this platform")));
Right now it is burried down inside a bunch of define tests.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
"Magnus Hagander" <mha@sollentuna.net> writes:
>> The only part of this discussion that I'd really be prepared=20
>> to buy into
>> is the part about *if* you use -W or --pwfile, then set up pg_hba.conf
>> with MD5 as the default auth (because that's probably what the user
>> wants anyway).
> Ok. Here is a patch that does this.
... and rather severely mangles the comments, too; not to mention the
more basic problem that the comments will now be wrong.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Magnus Hagander wrote:
>> Might still be worth adding "--ident" as a parameter anyway, but in that
>> case only to help the distros that need it. Or not, because they already
>> have a way to deal with it.
> I think --ident would be very helpful, and we know with OS's support
> ident too.
If we're going to be doing sed-like substitutions on pg_hba.conf.sample,
then we really really wanna discourage distros from hacking the sample
file directly, because that could break the sed results. So I think
it's important to provide the switch.
I was toying with the notion of a different editing mechanism though,
so that initdb could emit a pg_hba.conf containing comments that are
actually pertinent to the selected behavior. One simple way would be to
prefix each line with a keyword to select when to emit it:
ALWAYS this text is always emitted
NEVER this text is never emitted (a meta-comment)
TRUST this text is emitted if we're selecting TRUST mode
IDENT this text is emitted if we're selecting IDENT mode
etc.
regards, tom lane
On Tue, 2004-07-13 at 22:27, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I think --ident would be very helpful, and we know with OS's support > > ident too. > > If we're going to be doing sed-like substitutions on pg_hba.conf.sample, > then we really really wanna discourage distros from hacking the sample > file directly, because that could break the sed results. So I think > it's important to provide the switch. Speaking for Debian, I should like to explain how pg_hba.conf is managed (at least at present and probably in the next stable release). The basic assumption is that a system-installed package is of universal applicability, so there is only one (official) database cluster. The configuration files in that cluster are actually symlinks to /etc/postgresql/*. The Debian packaged version of initdb is hacked to write those symlinks rather than copy the sample files. (An extra command option --debian-conffile does this, and is used by the installation script.) (A local user running initdb in his own space would get the upstream behaviour, but this is not the normal case for package installations.) The reasons for the changes are found in Debian policy: 1. All configuration files [conffiles] must be in /etc . [motivation: administrators should be able to find configuration files quickly, without having to research each package separately.] 2. No conffile may be changed by a package upgrade without the administrator's consent. A package (such as postgresql) cannot simply overwrite a conffile such as pg_hba.conf with a new version. Its new version is written in parallel (/etc/postgresql/pg_hba.conf.dpkg-new) and only overwrites the old one if the administrator consents. [motivation: system administrators should not be surprised by having their systems redefined without their consent.] The default pg_hba.conf installed by a new package installation is configured thus: local all postgres ident sameuser local all all ident sameuser host all all 127.0.0.1 255.255.255.255 ident sameuser host all all ::1 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff ident sameuser host all all ::ffff:127.0.0.1/128 ident sameuser host all all 0.0.0.0 0.0.0.0 reject that is, to accept local connections authenticated by ident and reject the rest. The adminstrator is advised not to change the first line, so as to allow cron jobs to run. [motivation: to install the package with a sufficient level of security that it will not open the machine to remote exploits and to ensure that local users cannot spoof their identity to the database or change other people's data without permission. We trust the local ident server, since it is installed by the same administrator that is installing postgresql.] The point of this explanation is that as Debian maintainer I would have to disable any procedures that attempt to edit these conffiles, or at least ensure that their operation is under package control and produce only the effects that I desire. When initdb is rerun during major upgrades, it must then leave the previous configuration unchanged. Ensuring this is part of ensuring a smooth upgrade path, which is a major part of the package maintainer's job. -- Oliver Elphick olly@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA ======================================== "Let your character be free from the love of money, being content with what you have; for He Himself has said, "I will never desert you, nor will I ever forsake you." Hebrews 13:5
Oliver Elphick <olly@lfix.co.uk> writes:
> ...
> The point of this explanation is that as Debian maintainer I would have
> to disable any procedures that attempt to edit these conffiles, or at
> least ensure that their operation is under package control and produce
> only the effects that I desire.
Uh, is this relevant at all? There has been no suggestion that initdb
should try any harder or less hard than it does now to write
$PGDATA/pg_hba.conf. All that's been discussed is what it should write
there. If you are going to hack on it to enforce your opinion of what
it should do, then you'll be making the same hack either way.
regards, tom lane
On Wed, 2004-07-14 at 05:08, Tom Lane wrote: > Oliver Elphick <olly@lfix.co.uk> writes: > > ... > > The point of this explanation is that as Debian maintainer I would have > > to disable any procedures that attempt to edit these conffiles, or at > > least ensure that their operation is under package control and produce > > only the effects that I desire. > > Uh, is this relevant at all? There has been no suggestion that initdb > should try any harder or less hard than it does now to write > $PGDATA/pg_hba.conf. All that's been discussed is what it should write > there. If you are going to hack on it to enforce your opinion of what > it should do, then you'll be making the same hack either way. It's just that if people are going to do things to initdb to accommodate the distributions, they need to understand the constraints. -- Oliver Elphick olly@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA ======================================== "God is faithful, by whom ye were called unto the fellowship of his Son Jesus Christ our Lord." I Corinthians 1:9