On Mon, Nov 21, 2011 at 18:43, Diego Elio Petten=F2
<flameeyes@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 =97 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.
--=20
=A0Magnus Hagander
=A0Me: http://www.hagander.net/
=A0Work: http://www.redpill-linpro.com/