Re: [PATCHES] [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 initdb_pwd.patch Description: initdb_pwd.patch ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Is trust really a good default?
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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] Is trust really a good default?
Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Is trust really a good default?
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; Um, no, it doesn't. At least not on my installation. not to mention the more basic problem that the comments will now be wrong. That, however, it is correct :-( Sloppy. How about a text along the line of: CAUTION: Configuring the system for trust authentication allows any local user to connect using any PostgreSQL user name, including the superuser, over either Unix domain sockets or TCP/IP. If you are on a multiple-user machine, this is probably not good. Change it to use something other than trust authentication. Or something along that line? Since it would no longer actually be default. Or do we want something like On some installations, the default is...? //Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [HACKERS] Is trust really a good default?
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] Is trust really a good default?
On Tue, 2004-07-13 at 22:27, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 hostall all 127.0.0.1 255.255.255.255 ident sameuser hostall all ::1::::::: ident sameuser hostall all :::127.0.0.1/128 ident sameuser hostall all 0.0.0.00.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 [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] Is trust really a good default?
Robert Treat wrote: Woh, I didn't think we agreed that the default would change from 'trust', only that we would now emit a warning and allow other authentication methods to be specified at initdb time. I sure hope not (and that was my understanding as well) Incidentally that warning is a little misleading since it isn't just trust authentication that allows the wide open connections, but the combo of all users / all dbs / trust that does it. For example on one of my development machine I have a guest user who only has read access to a specific database from a limited subnet, but with trust authentication since random people inside the company will sometimes want to take a look at what I am cooking up. For my needs I use the superuser account who can access all databases but must come through ident on a unix socket. Different strokes for different folks eh? Sure, but the point is that the 'trust' line added by initdb is wide-open. Folks who do that fine-grained control will not get confused by the warning, hopefully. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] Is trust really a good default?
Magnus Hagander wrote: not to mention the more basic problem that the comments will now be wrong. That, however, it is correct :-( Sloppy. How about a text along the line of: CAUTION: Configuring the system for trust authentication allows any local user to connect using any PostgreSQL user name, including the superuser, over either Unix domain sockets or TCP/IP. If you are on a multiple-user machine, this is probably not good. Change it to use something other than trust authentication. Or something along that line? Since it would no longer actually be default. Or do we want something like On some installations, the default is...? Woh, I didn't think we agreed that the default would change from 'trust', only that we would now emit a warning and allow other authentication methods to be specified at initdb time. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Is trust really a good default?
On Tue, 2004-07-13 at 17:44, Bruce Momjian wrote:
Magnus Hagander wrote:
not to mention the
more basic problem that the comments will now be wrong.
That, however, it is correct :-( Sloppy.
How about a text along the line of:
CAUTION: Configuring the system for trust authentication allows any
local user to connect using any PostgreSQL user name, including the
superuser, over either Unix domain sockets or TCP/IP. If you are on
a multiple-user machine, this is probably not good. Change it to use
something other than trust authentication.
Or something along that line? Since it would no longer actually be
default. Or do we want something like On some installations, the
default is...?
Woh, I didn't think we agreed that the default would change from
'trust', only that we would now emit a warning and allow other
authentication methods to be specified at initdb time.
I sure hope not (and that was my understanding as well)
Incidentally that warning is a little misleading since it isn't just
trust authentication that allows the wide open connections, but the
combo of all users / all dbs / trust that does it. For example on one
of my development machine I have a guest user who only has read access
to a specific database from a limited subnet, but with trust
authentication since random people inside the company will sometimes
want to take a look at what I am cooking up. For my needs I use the
superuser account who can access all databases but must come through
ident on a unix socket. Different strokes for different folks eh?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] Is trust really a good default?
Oliver Elphick [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
