Re: [PATCHES] initdb authentication
Patch applied. Thanks. I just cleaned up some of the code formatting. --- Magnus Hagander wrote: Ok, here is another one. Doc patches coming up if/when this one is approved. //Magnus -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: den 17 juli 2004 03:11 To: Magnus Hagander Cc: [EMAIL PROTECTED] Subject: Re: [PATCHES] initdb authentication I got a new idea on this. I think we should add an initdb option that takes a string to specify the local authentication method: initdb --localauth 'ident' or whatever the user wants. I think this is more flexible and more compact. It would default to 'trust', and the packagers could set it to whatever they want. If their OS supports local ident, they can use that. Also keep in mind you might want some ident map file: initdb --localauth 'ident mymap' so you would need to allow multiple words in the string. --- Magnus Hagander wrote: Here's a version of this patch that includes documentation updates. //Magnus Content-Description: initdb_auth.patch [ Attachment, skipping... ] -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] initdb authentication
Ok, here is another one. Doc patches coming up if/when this one is approved. //Magnus + /* Kerberos methods not listed because they are not supported +* over local connections and are rejected in hba.c */ Is this true of all local connections, or only Unix socket connections? After all, this patch adjusts one 'local' line and 2 'host' lines. Maybe we would just need to tell people that if they want Kerberos they would have to do it by hand, rather than using this flag. It's true of 'local', meaning Unix socket connections. Something along that line about kerberos should go in the docs, yes :-) //Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] initdb authentication
Peter Eisentraut wrote: Magnus Hagander wrote: Ok, here is another one. Doc patches coming up if/when this one is approved. I think this warning is seriously going to annoy me. Can we do without it? What if we skip the warning if the user specifically asks for 'trust'? Would that help? -- 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] initdb authentication
This one makes it mandatory to pick some kind of authentication. If that's not wanted, it's easy to change it to default to trust (which I think is wrong, but we've been through that already..) I don't think I like any of this. Sooner rather than later, people need to look at pg_hba.conf and think about it. I don't like switches that induce them to skip that step. My guess is that a whole lot (I'd go as far as to say most) users don't do this. Instead they start the system in whatever is default, *and think it's secure enough*. Therefor, the default should be a reasonable guess at the securest thing they want. And setting trust is not that. Sort of like MSSQL permitting and defaulting to a blank sa password in earlier versions. Even MS fixed that. Yes, it took a worm for them to do it, but they did... If you want to fix that the whole way, install a pg_hba.conf *without anything*. That way nobody can connect and use their database until they edit it. (Turns out that is the same thing my patch does except it lets you set it on the commandline to initdb instead of having to edit the file assuming you just want local auth) And I certainly don't like forcing extra switches on users that just try out an installation locally. Oh, you mean along the line of having to create a separate user account to run it under? I'd say that is a whole lot more work than just entering a password. Or *explicitly* chosing that you want trust authentication. This very argument was shot down pretty quickly last time it came up in just a slightly different context, but it keeps popping up... I would be in favor of making everything supertight and secure by default, no questions asked. The is a definable goal. But as long as there is no agreement on that, let's not create illusions in that direction while inconveniencing a bunch of people for little gain. I think the basic problem is that right now there is no way to do an initdb and have it be secure _before_ you edit pg_hba.conf. That isn't acceptable. My thoughts exactly. Because most users *will not* edit pg_hba.conf until they need it to enable something, this is a problem. If I am on an insecure machine, the window if time between initdb and editing of pg_hba.conf is pretty bad. I could edit pg_hba.conf.sample, but then I am editing a sample file. Um. No. initdb does not start the database. You're safe until you start postmaster. This is defence against the fact that most users will start the database without editing (or looking at, or for that matter even be aware of the existance of) pg_hba.conf. I think Magnus's patch takes us closer to secure. I do agree that by default we shouldn't require any flag and install unsecure and issue a warning. I say that warning should be in the form of if you realy want this, append --trust to the command you just issued, but any step towards it is a step in the right direction :-) //Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] initdb authentication
Here's a version of this patch that includes documentation updates. //Magnus -Original Message- From: Magnus Hagander Sent: den 15 juli 2004 23:02 To: [EMAIL PROTECTED] Subject: [PATCHES] initdb authentication Ok, here is one more try at the initdb default authentication stuff. This one adds the switches --ident and --trust, which will configure pg_hba.conf with ident and trust authentication respectively. If trust authentication is selected, a warning is written to pg_hba.conf. The old switches for password prompt/file still apply. This one makes it mandatory to pick some kind of authentication. If that's not wanted, it's easy to change it to default to trust (which I think is wrong, but we've been through that already..) Oh, and this time, the comments are updated :-) //Magnus initdb_auth.patch Description: initdb_auth.patch ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] initdb authentication
I got a new idea on this. I think we should add an initdb option that takes a string to specify the local authentication method: initdb --localauth 'ident' or whatever the user wants. I think this is more flexible and more compact. It would default to 'trust', and the packagers could set it to whatever they want. If their OS supports local ident, they can use that. Also keep in mind you might want some ident map file: initdb --localauth 'ident mymap' so you would need to allow multiple words in the string. --- Magnus Hagander wrote: Here's a version of this patch that includes documentation updates. //Magnus -Original Message- From: Magnus Hagander Sent: den 15 juli 2004 23:02 To: [EMAIL PROTECTED] Subject: [PATCHES] initdb authentication Ok, here is one more try at the initdb default authentication stuff. This one adds the switches --ident and --trust, which will configure pg_hba.conf with ident and trust authentication respectively. If trust authentication is selected, a warning is written to pg_hba.conf. The old switches for password prompt/file still apply. This one makes it mandatory to pick some kind of authentication. If that's not wanted, it's easy to change it to default to trust (which I think is wrong, but we've been through that already..) Oh, and this time, the comments are updated :-) //Magnus Content-Description: initdb_auth.patch [ Attachment, skipping... ] ---(end of broadcast)--- TIP 8: explain analyze is your friend -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] initdb authentication
Ok, here is one more try at the initdb default authentication stuff. This one adds the switches --ident and --trust, which will configure pg_hba.conf with ident and trust authentication respectively. If trust authentication is selected, a warning is written to pg_hba.conf. The old switches for password prompt/file still apply. This one makes it mandatory to pick some kind of authentication. If that's not wanted, it's easy to change it to default to trust (which I think is wrong, but we've been through that already..) Oh, and this time, the comments are updated :-) //Magnus initdb_auth.patch Description: initdb_auth.patch ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] initdb authentication
Magnus Hagander wrote: This one makes it mandatory to pick some kind of authentication. If that's not wanted, it's easy to change it to default to trust (which I think is wrong, but we've been through that already..) I don't think I like any of this. Sooner rather than later, people need to look at pg_hba.conf and think about it. I don't like switches that induce them to skip that step. And I certainly don't like forcing extra switches on users that just try out an installation locally. I would be in favor of making everything supertight and secure by default, no questions asked. The is a definable goal. But as long as there is no agreement on that, let's not create illusions in that direction while inconveniencing a bunch of people for little gain. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] initdb authentication
Peter Eisentraut wrote: Magnus Hagander wrote: This one makes it mandatory to pick some kind of authentication. If that's not wanted, it's easy to change it to default to trust (which I think is wrong, but we've been through that already..) I don't think I like any of this. Sooner rather than later, people need to look at pg_hba.conf and think about it. I don't like switches that induce them to skip that step. And I certainly don't like forcing extra switches on users that just try out an installation locally. I would be in favor of making everything supertight and secure by default, no questions asked. The is a definable goal. But as long as there is no agreement on that, let's not create illusions in that direction while inconveniencing a bunch of people for little gain. I think the basic problem is that right now there is no way to do an initdb and have it be secure _before_ you edit pg_hba.conf. That isn't acceptable. If I am on an insecure machine, the window if time between initdb and editing of pg_hba.conf is pretty bad. I could edit pg_hba.conf.sample, but then I am editing a sample file. I think Magnus's patch takes us closer to secure. I do agree that by default we shouldn't require any flag and install unsecure and issue a warning. -- 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 8: explain analyze is your friend
Re: [PATCHES] initdb authentication
On Thu, Jul 15, 2004 at 11:20:46PM +0200, Peter Eisentraut wrote: Magnus Hagander wrote: This one makes it mandatory to pick some kind of authentication. If that's not wanted, it's easy to change it to default to trust (which I think is wrong, but we've been through that already..) I don't think I like any of this. Sooner rather than later, people need to look at pg_hba.conf and think about it. I don't like switches that induce them to skip that step. And I certainly don't like forcing extra switches on users that just try out an installation locally. I agree with this sentiment. On the spanish list is common to see people trying to do things on an RPM-installed server, which is configured to use IDENT by default, and asking why they cannot connect. The answer is always to look at pg_hba.conf and the relevant documentation. If it were my choice, I'd disallow connections by default completely, and spit a reject message along the lines of you should have a look at pg_hba.conf. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Uno combate cuando es necesario... ¡no cuando está de humor! El humor es para el ganado, o para hacer el amor, o para tocar el baliset. No para combatir. (Gurney Halleck) ---(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] initdb authentication
Bruce Momjian [EMAIL PROTECTED] writes: I think the basic problem is that right now there is no way to do an initdb and have it be secure _before_ you edit pg_hba.conf. That isn't acceptable. If I am on an insecure machine, the window if time between initdb and editing of pg_hba.conf is pretty bad. Bruce, you of all people should be aware that there is no such window. The postmaster *is not running* and cannot accept any hostile connections if you haven't started it. Argue all you like about the potential for novice error, but don't try to scare us by claiming that it's inherently insecure. regards, tom lane ---(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] initdb authentication
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I think the basic problem is that right now there is no way to do an initdb and have it be secure _before_ you edit pg_hba.conf. That isn't acceptable. If I am on an insecure machine, the window if time between initdb and editing of pg_hba.conf is pretty bad. Bruce, you of all people should be aware that there is no such window. The postmaster *is not running* and cannot accept any hostile connections if you haven't started it. Argue all you like about the potential for novice error, but don't try to scare us by claiming that it's inherently insecure. Ah, I forgot about postmaster start. (My scripts do it automatically here.) Maybe we just need to print a warning telling people they should secure pg_hba.conf before starting the postmaster on an insecure machine. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
