Re: [HACKERS] Spoofing as the postmaster
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Agreed. Requiring client root certificate checking is heavy-handed. There seems to be some confusion here. I didn't think anyone was proposing that we force every installation to require client root certificate checking. What was under discussion (I thought) was providing the ability for a DBA to *choose* to require it. Ok, at least someone is partly lost in this discussion, and I'm getting a sneaky suspicion it's me :-) We already *do* allow the DBA to choose this, no? If you put the root certificate on the client, it *will* verify the server cert, and it *will* refuse to connect to a server that can't present a trusted root cert. Hang on, maybe I get what you're referring to now - we don't check the Common Name field on the certificate, so *any* trusted certificate would be ok. Incorrect common name generally results in a warning in a browser, for example, but we accept it fine. We do store it in conn-peer_cn, so the client can check it if they need to. But we don't enforce. Or are you saying that the *server* should require that the client has done verification, by a config string? If so, I just don't see how that's possible in any meaningful way. Of course I am not sure anyone knows how to get that information from SSL. Yeah, if OpenSSL doesn't support testing for this then the discussion is moot... AFAIK, our current OpenSSL code supports verifying both client and server certificates. If we want to, as Bruce suggested, emit a log message when the client hasn't provided a certificate, we can certainly do so. But I thought this thread was about impersonating the server, not the client... Emitting such a log message in cases where the system isn't configured to use client certificates at all would cause a whole lot of unnecessary logging for all cases that don't use client certificates. And if you *do* use client certificates, it's not going to get emitted because you can't even *connect* without having it. Now, if/when we actually support authenticating with client certificates (as I said, I hope to work on this), the equation is different because then you can set it per hba using authentication method. But just enabling such a thing globally is a very blunt instrument... //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Spoofing as the postmaster
Mark Mielke wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Agreed. Requiring client root certificate checking is heavy-handed. There seems to be some confusion here. I didn't think anyone was proposing that we force every installation to require client root certificate checking. What was under discussion (I thought) was providing the ability for a DBA to *choose* to require it. Of course I am not sure anyone knows how to get that information from SSL. Yeah, if OpenSSL doesn't support testing for this then the discussion is moot.. I believe SSL is only capable of letting you know whether authentication for each end point was 1) not requested, 2) optional requested, or 3) required. Note that even if the authentication is required, there is no way to know how authentication was performed. For example, did it check the signature chain, requiring it to map to a public root certificate lists used by most web browsers? If so, did it check the contents of the certificate, or is only checking that it exists? Did it check a local key store that has a copy of the public key certificate? Or did it just log the certificate subject? That is exactly my point. The server can never know if the client has actually verified anything. It can provide the client with the *means* to verify things, but it can't enforce it. A naive implementation would have a flag in the protocol that says enforce client to validate server certs. The MITM attacker could then just remove this flag in the stream before it arrives at the client, and it's gone. And the kind of attack we would be trying to protect from here is exactly the one that can trivially remove such a check. It would just be a no-op with administrative overhead, really. The bottom line is that the server cannot be responsible for client security. Only the client can. OpenSSH, for instance, presents the user with the finger print of the certificate and asks you: $ ssh 192.168.0.1 The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established. RSA key fingerprint is 3e:a7:0f:04:60:7e:8e:64:52:bf:81:92:a9:05:c7:36. Are you sure you want to continue connecting (yes/no)? While this certainly gives you the opportunity to challenge it, I don't know of any person who actually checks this finger print. Luckily, it stores it to ~/.ssh/known_hosts, and so the real issue is if it suddenly changes, you get a warning. Still, I've seen the warning before, and realized that oh yes, that machine was upgraded, so it probably has a new public key. I have never personally checked the finger print against a known source. Authentication is only as strong as the person or process confirming it. In the case of trying to force a client to authenticate the server, this requires the client to know who the server is. As most clients will not know who the server is, I see clients implementing an OpenSSH-style authentication model (shown above), or providing their own no-op authentication routine to OpenSSL. I don't think it is worth it, and I don't think it would work. Yeah, it *is* decent protection against it suddenly changing. But as you say, that requires the original fingerprint to be stored at the client. Just like if you store the root or server cert on a libpq client, it will refuse to connect if the server suddenly presents an untrusted certificate. (So in that way we're actually *more* secure than OpenSSH, since we don't give you a prompt to ignore an untrusted root cert - we just refuse to connect. Unless you manually disable the check by removing the file.) //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Spoofing as the postmaster
On Sat, Dec 29, 2007 at 12:40:24PM +0100, Magnus Hagander wrote: We already *do* allow the DBA to choose this, no? If you put the root certificate on the client, it *will* verify the server cert, and it *will* refuse to connect to a server that can't present a trusted root cert. I think Tom's point is that we don't allow this for connections over a Unix Domain socket. And thus we should remove the asymmetry so the verification can work for them also. Personally I quite liked the idea of having a serveruser=foo which is checked by getting the peer credentials. Very low cost, quick setup solution. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F Kennedy signature.asc Description: Digital signature
Re: [HACKERS] Spoofing as the postmaster
Martijn van Oosterhout wrote: On Sat, Dec 29, 2007 at 12:40:24PM +0100, Magnus Hagander wrote: We already *do* allow the DBA to choose this, no? If you put the root certificate on the client, it *will* verify the server cert, and it *will* refuse to connect to a server that can't present a trusted root cert. I think Tom's point is that we don't allow this for connections over a Unix Domain socket. And thus we should remove the asymmetry so the verification can work for them also. If that's where we still are, then I'm all for that provided it doesn't add a whole lot of complexity, as I think I said before. I thought we were now talking general SSL connections. That could be where I lost the thread :-) Personally I quite liked the idea of having a serveruser=foo which is checked by getting the peer credentials. Very low cost, quick setup solution. It would still only tell you the user and not the postmaster ;-) But yes, it does help in the unix domain case (but not TCP-over-localhost). Either that, or a function that returns the peer credentials if available - like we have for SSL today. Then the client could do some more advanced checking if necessary - like allowing multiple different accounts if wanted. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Spoofing as the postmaster
Mark Mielke wrote: Magnus Hagander wrote: Mark Mielke wrote: I have done this for my own application before. Although the client and server use standard TLS 1.0 to speak to each other with a required authentication of RSA 1024-bit and a required encryption of AES 128-bit, it still requires that passwords sent from the client to the server are RSA encrypted using the server public certificate, making it impossible for anybody except for the legitimate server to see the password. One benefit of this is that the password itself can be '\0'd out as soon as we have RSA encrypted it, and things like a core dump of the client have a lower chance of including the password in plain text. Why are you even using a password in this case, and not just key-based auth? Wouldn't that be even easier and more secure? Users of this product don't have keys - they have passwords. The username/password is for per-user authentication. The username defines the access level. Many users will use the same client. The client does have its own private RSA key and public certificate, however, this grants entry to the system. Password login is still required by the users of the client. And you have one private key *per client*? That's an interesting approach - and actually how pg will work if you enable client cert checking :-) It's probably about as far as you can get as long as you use passwords. If you want something that's really secure, you just have to give up using passwords. Solutions like one-time passwords from a token or certificates on a smartcard are what people use then :-) At what point does prudence become paranoia? I don't know. In my case, I felt 128-bit encryption was insufficient for protecting the passwords in my application. 256-bit encryption would have been sufficient, but that cannot yet be safely exported from the US to the countries I required. How do you protect the certificate store on the client? Or the binary that ends up prompting for the password on the client The certificate on the client grants access to the system. It does not grant access to the resources on the system. Two-level authentication with mandatory server authentication. You see similar things in physical security instances. A security badge lets you in the door - but you still need to login to the computer once you get in. As for protecting the binary that prompts for a password on the client - I didn't bother with this, although Java does allow for signed jar files that would allow the user to be assured that the client is legitimate. Only as long as you can trust the JRE... And the OS... (yeah, reaching, but still goes to prove the point that the system *cannot* be secure if people can chance your client code/machine. It can be secure from a server or network POV, but not froma client one) There are always loops though, just because the client is legitimate doesn't mean that the keyboard is, and so on. You end up putting in enough effort to mitigate the risk. The risk always exists, but through clever, cryptographic, or obfuscatory measures, the risk can be greatly reduced. Right. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Archiver behavior at shutdown
On Fri, 2007-12-28 at 20:20 -0500, Greg Smith wrote: On Sat, 29 Dec 2007, Simon Riggs wrote: System Shutdown System shuts down, postmaster shuts down, archiver works furiously until the end trying to archive things away. Archiver gets caught half way through copy, so crashes, leaving archiver.pid. Subsequent startup sees archiver.pid, postmaster reads file to get pid, then sends signal to archiver to see if it is still alive, it isn't so remove archiver.pid and allow next archiver to start. Isn't it possible some other process may have started with that pid if the database server was down for long enough? In that case sending a signal presuming it's the archive process that used to have that pid might be bad form. I think you've emphasised my point that me rushing this in the time I have available is not going to improve matters for the group. My original one line change described on bug 3843 seems like the best solution for 8.3. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Spoofing as the postmaster
On Sat, 29 Dec 2007 12:45:26 +0100 Magnus Hagander [EMAIL PROTECTED] wrote: That is exactly my point. The server can never know if the client has actually verified anything. It can provide the client with the *means* to verify things, but it can't enforce it. I know this is probably obvious to most people in this discussion and I don't mean to impugn Magnus just because I am latching onto his message to make this point but I suspect that this discussion would go a lot smoother if it branches into two completely different discussions about two completely different issues; - 1: How does the client assure that the postmaster is legit - 2: How does the postmaster assure that the client is legit Does anyone think that there is one answer to both? -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Spoofing as the postmaster
Magnus Hagander wrote: Mark Mielke wrote: Why are you even using a password in this case, and not just key-based auth? Wouldn't that be even easier and more secure? Users of this product don't have keys - they have passwords. The username/password is for per-user authentication. The username defines the access level. Many users will use the same client. The client does have its own private RSA key and public certificate, however, this grants entry to the system. Password login is still required by the users of the client. And you have one private key *per client*? That's an interesting approach - and actually how pg will work if you enable client cert checking :-) Yep. It's probably about as far as you can get as long as you use passwords. If you want something that's really secure, you just have to give up using passwords. Solutions like one-time passwords from a token or certificates on a smartcard are what people use then :-) Yes. Pseudo-random number generator on an LCD display that changes every 60 seconds, or one of those government satellite-based systems. :-) Even still, it's often two forms of authentication. With the SecureID cards, the number proves you have the physical card on your possession, and the password proves you have access to the person's brain (or piece of paper that they stupidly wrote their password on :-) ). Most of these systems are not necessarily effective against kidnapping the person and threatening to kill them. However, they are very effective against random hackers on the Internet who are doing trial and error or some other approach. By denying entry BEFORE the password is provided, they are unable to guess passwords and get lucky. The certificate on the client grants access to the system. It does not grant access to the resources on the system. Two-level authentication with mandatory server authentication. You see similar things in physical security instances. A security badge lets you in the door - but you still need to login to the computer once you get in. As for protecting the binary that prompts for a password on the client - I didn't bother with this, although Java does allow for signed jar files that would allow the user to be assured that the client is legitimate. Only as long as you can trust the JRE... And the OS... (yeah, reaching, but still goes to prove the point that the system *cannot* be secure if people can chance your client code/machine. It can be secure from a server or network POV, but not froma client one) Correct. I believe this is why I didn't bother. I saw value to using better than 128-bit AES for the password (as per US export control regulations), but not for the data (the data was primarily a list of privileged write requests), and I saw value to making the password unreadable as soon as possible (the client might be long running, but it turns the password into RSA encrypted data soon after you hit ENTER, and reuses this for the length of the session if the password is required again). I didn't see value to protecting the client. There are always loops though, just because the client is legitimate doesn't mean that the keyboard is, and so on. You end up putting in enough effort to mitigate the risk. The risk always exists, but through clever, cryptographic, or obfuscatory measures, the risk can be greatly reduced. Right If it was an easy problem, somebody would have solved it once and for all, and the CIA would be out of business... :-) Cheers, mark -- Mark Mielke [EMAIL PROTECTED]
Re: [HACKERS] Spoofing as the postmaster
D'Arcy J.M. Cain wrote: - 1: How does the client assure that the postmaster is legit - 2: How does the postmaster assure that the client is legit And neither answers the original problem: 3. How can the sysadmin prevent a malicious local user from hijacking the sockets if the postmaster isn't running? Prevention is much more valuable than ex post detection, IMNSHO. Probably the first answer is not to run postgres on a machine with untrusted users, but that's not always possible. Maybe we can't find a simple cross-platform answer, but that doesn't mean we should not look at platform-specific answers, at least for documentation. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Spoofing as the postmaster
On Sat, 29 Dec 2007 10:38:13 -0500 Andrew Dunstan [EMAIL PROTECTED] wrote: D'Arcy J.M. Cain wrote: - 1: How does the client assure that the postmaster is legit - 2: How does the postmaster assure that the client is legit And neither answers the original problem: Which seems to have been lost in the noise. 3. How can the sysadmin prevent a malicious local user from hijacking the sockets if the postmaster isn't running? A better way of stating it for sure. Prevention is much more valuable than ex post detection, IMNSHO. Probably the first answer is not to run postgres on a machine with untrusted users, but that's not always possible. Maybe we can't find a simple cross-platform answer, but that doesn't mean we should not look at platform-specific answers, at least for documentation. Yes, that's what I said at the start of this discussion. If you don't trust the users with actual access to the box, the rest of this is pretty much academic. -- D'Arcy J.M. Cain [EMAIL PROTECTED] | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Spoofing as the postmaster
* D'Arcy J.M. Cain ([EMAIL PROTECTED]) wrote: Probably the first answer is not to run postgres on a machine with untrusted users, but that's not always possible. Maybe we can't find a simple cross-platform answer, but that doesn't mean we should not look at platform-specific answers, at least for documentation. Yes, that's what I said at the start of this discussion. If you don't trust the users with actual access to the box, the rest of this is pretty much academic. Academic from an upstream standpoint, but there are platform-specific / setup-specific things you can do (SELinux, vserver/jails, Kerberos, SSL, etc...). Documenting it is good, but I think it should really be to the extent of saying look, 5432 is unprivledged, here are some ways to deal with that and you should probably put the PG unix socket in a secured directory (though Debian and I suspect many other distributions do this part for you). Enjoy, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Spoofing as the postmaster
Andrew Dunstan wrote: D'Arcy J.M. Cain wrote: - 1: How does the client assure that the postmaster is legit - 2: How does the postmaster assure that the client is legit And neither answers the original problem: 3. How can the sysadmin prevent a malicious local user from hijacking the sockets if the postmaster isn't running? Prevention is much more valuable than ex post detection, IMNSHO. Probably the first answer is not to run postgres on a machine with untrusted users, but that's not always possible. Maybe we can't find a simple cross-platform answer, but that doesn't mean we should not look at platform-specific answers, at least for documentation. I thought this answer was already provided: Put the socket in a directory that is only writable by the database owner. The socket is created as part of the bind() process. I think this covers 90%+ of it, and is already in use by distributions. The only thing better this team could do would be to formalize it? The serveruser= db open parameter might be enough to lock it up tight if there is still a race condition on bind(). It's effectively a very cheap authentication mechanism that does not require expensive cryptographic operations. There is probably value to making SSL consistent for TCP/UNIX sockets as Tom suggests. Removing the inconsistency as it were, and allowing for SSL authentication and encryption for UNIX sockets the same as for TCP sockets. If it was as simple as removing an if statement that would be even cooler... :-) What has come out for me is that this isn't UNIX socket specific at all (although there may be UNIX socket specific options available). The standard PostgreSQL port is above 1024, and anybody could bind()/listen()/accept() on it, assuming it is not running. This is where your first answer of running PostgreSQL on a machine with trusted users comes in as a sensible recommendation, even if only some people are willing to accept this recommendation. :-) Cheers, mark -- Mark Mielke [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Spoofing as the postmaster
Magnus Hagander wrote: Martijn van Oosterhout wrote: On Sat, Dec 29, 2007 at 12:40:24PM +0100, Magnus Hagander wrote: We already *do* allow the DBA to choose this, no? If you put the root certificate on the client, it *will* verify the server cert, and it *will* refuse to connect to a server that can't present a trusted root cert. I think Tom's point is that we don't allow this for connections over a Unix Domain socket. And thus we should remove the asymmetry so the verification can work for them also. If that's where we still are, then I'm all for that provided it doesn't add a whole lot of complexity, as I think I said before. I thought we were now talking general SSL connections. That could be where I lost the thread :-) I think the user-visible impact of that addition would be to add 'localssl' in pg_hba.conf. It would be nice if we had made SSL control separate from the connection type, and perhaps we will explore that in 8.4. (None of this is 8.3, I believe.) -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Spoofing as the postmaster
Mark Mielke wrote: Andrew Dunstan wrote: D'Arcy J.M. Cain wrote: - 1: How does the client assure that the postmaster is legit - 2: How does the postmaster assure that the client is legit And neither answers the original problem: 3. How can the sysadmin prevent a malicious local user from hijacking the sockets if the postmaster isn't running? Prevention is much more valuable than ex post detection, IMNSHO. Probably the first answer is not to run postgres on a machine with untrusted users, but that's not always possible. Maybe we can't find a simple cross-platform answer, but that doesn't mean we should not look at platform-specific answers, at least for documentation. I thought this answer was already provided: Put the socket in a directory that is only writable by the database owner. The socket is created as part of the bind() process. I think this covers 90%+ of it, and is already in use by distributions. The only thing better this team could do would be to formalize it? The serveruser= db open parameter might be enough to lock it up tight if there is still a race condition on bind(). It's effectively a very cheap authentication mechanism that does not require expensive cryptographic operations. It's in use by some distributions, hardly all, or even a majority. AFAIK it's only in Debian + descendants. Anyway, I think it could arguably make matters worse, not better, by guaranteeing that the postmaster can start up even if the TCP socket has been hijacked . That's why I suggested it might be useful to have a switch that says don't start if any interface fails to bind (which was the old pre-8.0 behaviour). It might well be useful for us to look at drafting an SELinux policy, even if it's not universal. After all, this situation is precisely the sort of thing that SELinux is about, ISTM. cheers andrew ---(end of broadcast)--- TIP 1: 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: [HACKERS] Spoofing as the postmaster
Andrew Dunstan [EMAIL PROTECTED] writes: It might well be useful for us to look at drafting an SELinux policy, There already is one. However, I'm not sure that it's ever been reviewed by anyone who's Postgres-savvy (I certainly haven't looked at it:-(). It would be useful for that to happen. Another thing is that we could stand to have some documentation on how to adjust the policy for local needs --- in particular, supporting tablespaces that're outside /var/lib/pgsql. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Spoofing as the postmaster
Mark Mielke [EMAIL PROTECTED] writes: What has come out for me is that this isn't UNIX socket specific at all (although there may be UNIX socket specific options available). The standard PostgreSQL port is above 1024, and anybody could bind()/listen()/accept() on it, assuming it is not running. Right. The real bottom line is that a socket in /tmp is exactly as secure as a localhost TCP port. There is no value in debating moving the default socket location unless you are prepared to also relocate the default port to below 1024 (and even that helps only on Unix-y platforms). I remain of the opinion that what we should do about this is support SSL usage over sockets and document the issues. regards, tom lane ---(end of broadcast)--- TIP 1: 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: [HACKERS] Spoofing as the postmaster
On Sat, 29 Dec 2007, Joshua D. Drake wrote: http://code.google.com/p/sepgsql/ ??? Getting that to work required some obtrusive changes to the source code, which they've only done to 8.2.4. Even that doesn't seem to be production-quality and it's not clear how that will make its way into newer versions yet. The job here is to work on the SELinux policies for PostgreSQL. You can't just re-use whatever work has gone into the SE-PostgreSQL ones, because those presume you're using their modified server instead of the regular one. I started collecting notes and writing a PostgreSQL/SELinux how-to aimed at RHEL 5.0+ but I'm not doing work in that area anymore. On reflection I might just release what I did so far to the developer's wiki and see if anybody else fills in the missing pieces. But unless there's somebody else with a burning need to work on this area I doubt that will happen--there's nothing about SELinux that anybody does just for fun. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Spoofing as the postmaster
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 29 Dec 2007 14:40:29 -0500 (EST) Greg Smith [EMAIL PROTECTED] wrote: On Sat, 29 Dec 2007, Joshua D. Drake wrote: http://code.google.com/p/sepgsql/ ??? Getting that to work required some obtrusive changes to the source code, which they've only done to 8.2.4. Even that doesn't seem to be production-quality and it's not clear how that will make its way into newer versions yet. they've has the potential to be we... As I recall the individual made a reasonable effort to introduce the work that he was doing to the community. http://archives.postgresql.org/pgsql-hackers/2007-03/msg00271.php http://archives.postgresql.org/pgsql-hackers/2007-04/msg00664.php The job here is to work on the SELinux policies for PostgreSQL. You can't just re-use whatever work has gone into the SE-PostgreSQL ones, because those presume you're using their modified server instead of the regular one. Fair enough. I was just trying to offer a source to start with. But unless there's somebody else with a burning need to work on this area I doubt that will happen--there's nothing about SELinux that anybody does just for fun. Ya think? :P I recognize that this SE PGSQL has the potential to be a portability nightmare (as it only works on linux) but it certainly has potential to give us a leg up on a lot of work. Anyway, not saying its good code but I did read the docs and it sure looks cool. Sincerely, Joshua D. Drake - -- The PostgreSQL Company: Since 1997, http://www.commandprompt.com/ Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHdqriATb/zqfZUUQRAk73AJ9/Gy2+5mjxBsbEZHyCycp/HgwR0wCfYHPw TaLkLocBWGpgP0Z7T+IaaWA= =0Zwj -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: 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: [HACKERS] Spoofing as the postmaster
On Sat, 29 Dec 2007, Joshua D. Drake wrote: they've has the potential to be we... As I recall the individual made a reasonable effort to introduce the work that he was doing to the community. After a bit of hindsight research, I think SE-PostgreSQL suffered from two timing problems combined with a cultural misperception. The first timing issue was that those messages went out just as the 8.3 feature freeze was going on. I know I looked at their stuff for a bit at that point, remembered I had patches to work on, and that was it at that point. The second problem is that just after the first message to the list came out, RedHat released RHEL 5.0, which did a major reworking of SELinux that everyone could for production systems immediately. I know all my SELinux time at that point immediately switched to working through the major improvements RHEL5 made rather than thinking about their project. The cultural problem is that their deliverable was a series of RPM packages (for Fedora 7, ack). They also have a nice set of user documentation. But you can't send a message to this hackers list asking for feedback and hand that over as your reference. People here want code. When I wander through the threads that died, I think this message shows the mismatch best: http://archives.postgresql.org/pgsql-hackers/2007-04/msg00722.php When Tom throws out an objection that a part of the design looks sketchy, the only good way to respond is to throw the code out and let him take a look. I never saw the SE-PostgreSQL group even showing diffs of what they did; making it easy to get a fat context diff (with a bit more context than usual) would have done wonders for their project. You're not going to get help from this community if people have to install a source RPM and do their own diff just to figure out what was changed from the base. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 1: 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: [HACKERS] Spoofing as the postmaster
Tom Lane wrote: This is basically the same old mutual authentication problem that SSL was designed to solve by using certificates. I don't think we have either the need or the expertise to re-invent that wheel. ISTM we have these action items: 1. Improve the code so that SSL authentication can be used across a Unix-socket connection ... Added to TODO: * Allow SSL authentication/encryption over unix domain sockets -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
