Re: [PG19-3 PATCH] Don't ignore passfile

On Thu, Sep 4, 2025 at 7:22 PM Paul Ohlhauser
<bendix(dot)ohlhauser(at)gmail(dot)com> wrote:
> > Another idea could be to fail the connection instead of treating this as a warning condition.
> As noted in the proposal, if the check stays I'd argue that it should be an error.
> I can't imaging a case where the user is happy with specifying a passfile and have it be ignored, but maybe somebody can think of a scenario.
> Other permission checks are already errors (as in /src/interfaces/libpq/fe-secure-openssl.c:1269)

While I agree that the user won't be happy, that's sort of the point.
The warning is trying to coerce the user into changing the file
permissions. It's very similar to what ssh does:

$ ssh-add x
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for 'x' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

> Converting the warning to an error and allowing group read permissions would be a solid solution IMO.
> If that turns out to be accepted, I'd be happy to update the patch but I have no experience with the codebase, nor professional C experience.
> I can give it a try, but it might be easier for everyone if someone more familiar with the code implements the change.
> Let me know how to proceed.

At present, my vote is to leave things as they are. Sure, that's a
debatable behavior, as you rightly point out. But every behavior here
is debatable. Trying to force the user to change permissions on their
files is debatable: who is to say we know best? Ignoring the file vs.
failing the connection must also be debatable, because you're debating
it. :-) What I like about the current behavior is not that I think
it's ideal or that it's what I would necessarily have chosen, but that
it's 17 years old. I can't see a clear reason to believe that your
complaint now is a good reason to override the complaint that led to
the current behavior back then. Now if a bunch of people show up and
say "well, actually, the Internet has standardized on handling this in
X way and you are not," or something like that, well then we should
change it. But I feel like we need a clear reason to believe either
that we made the wrong decision back then, or that the situation is
different now, and at the moment I'm not really seeing one. AFAIK this
is similar to what other tools do, as in the ssh example above.

--
Robert Haas
EDB: http://www.enterprisedb.com