On Nov 21, 2011 8:29 AM, "Diego Elio Pettenò" <flamee...@flameeyes.eu>
wrote:
>
>
> The following bug has been logged online:
>
> Bug reference: 6302
> Logged by: Diego Elio Pettenò
> Email address: flamee...@flameeyes.eu
> PostgreSQL version: 9.1.1
> Operating system: Gentoo Linux
> Description: Certificate lookup fails for users with /dev/null as
> home directory
> Details:
>
> A common way to make sure an user has no access to a home directory on
Unix
> is to set that directory to /dev/null. Unfortunately that causes the
stat()
> call to return an error when you're trying to check for the certificate.
> From 9.1.1, src/interfaces/libpq/fe-secure.c, line 1009 and counting:
>
>
> else if (stat(fnbuf, &buf) != 0)
> {
> /*
> * If file is not present, just go on without a client
cert;
> server
> * might or might not accept the connection. Any other
> error,
> * however, is grounds for complaint.
> */
> if (errno != ENOENT)
> {
> printfPQExpBuffer(&conn->errorMessage,
> libpq_gettext("could not open certificate file
> \"%s\": %s\n"),
> fnbuf,
> pqStrerror(errno, sebuf, sizeof(sebuf)));
> return -1;
> }
> have_cert = false;
> }
What actual error do you get?
> Interestingly enough, the .pgpass file check is not as strict; from
> fe-connect.c lines 4863 and counting:
>
>
> if (!getPgPassFilename(pgpassfile))
> return NULL;
>
> /* If password file cannot be opened, ignore it. */
> if (stat(pgpassfile, &stat_buf) != 0)
> return NULL;
>
> I suppose it might be a good idea to simply replicate the same logic for
the
> certificate, so that it restores the chance to use SSL connections on
users
> that have /dev/null as home directory, which right now is outright
> impossible.
>
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.
/Magnus
