On Mon, Nov 21, 2011 at 18:43, Diego Elio Pettenò <flamee...@flameeyes.eu> wrote: > Il giorno lun, 21/11/2011 alle 09.08 +0100, Magnus Hagander ha scritto: >> What actual error do you get? > > ENOTDIR, sorry but I don't really want to break my system again just to > show the strerror output ;)
So a simple extension of the check to be for both ENOENT and ENOTDIR would work, right? >> Its still impossible to use it securely, but I agree we shouldn't just >> error out in a situation like that - the user wanted to be insecure, >> after all.. But I'm not sure just dropping the check is the correct >> answer - adjusting it is probably a better idea. > > Whether non-user-certificate SSL is "unsecure" or not I guess is mostly > up to debate — I think that for many people, including me, simply having > host-based authentication should be quite secure, of course depending on > the use case. Without user certificate, yes, absolutely, that can be secure. Without validating the server certificate, however, it's kind of hard to actually call it secure. > The main problem there is that right now a very common Unix setup is > broken, and that's definitely not what you wanted in the first place. Oh yes, we want to fix this. > "Adjusting" the check doesn't seem to make much sense.. you'll still > fail with error in some other situation if you just whitelist ENOTDIR... > simply unify the codepaths, and if stat fails ignore the presence of the > certificate... what's the worst that may happen? I was originally going to say that we would not do server cert validation, but that's a different codepath now that I look at the whole thing. So yes, you'd fail. But in a scenario where you had say the wrong permissions on the file, we'd silently ignore it - this doesn't seem like the right thing to do. And it will cause scenarios hard to debug. However, unifying the code paths might be a good idea. But in that case, we also need to do permissions checks on the certificate file - which is probably a good idea in general. > Speaking of this, it might be a good idea to also change the code to > respect the HOME environment variable: in my case the home directory > could be dynamically set before starting the process, but since libpq > accesses the shadow database, instead of checking HOME, I can't fix it > properly that way. That's a different thing though. We'd have to do both though - but let $HOME override it. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
