Re: [PG19-3 PATCH] Don't ignore passfile - Mailing list pgsql-hackers
| From | Paul Ohlhauser |
|---|---|
| Subject | Re: [PG19-3 PATCH] Don't ignore passfile |
| Date | |
| Msg-id | CAGbOXJEJ2Dr8wS1QNno-ruzVX2FKDBTcdsuJ=HTdinN+K01MGg@mail.gmail.com Whole thread Raw |
| In response to | Re: [PG19-3 PATCH] Don't ignore passfile (Robert Haas <robertmhaas@gmail.com>) |
| List | pgsql-hackers |
> 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.
My point is not that the user is not happy, that they have to change permissions.
It is that the user would rather get a clear error message than to get two separate messages (warning that doesn't mention "ignore" and authentication error) they need to connect to understand what is going on.
> The warning is trying to coerce the user into changing the file
> permissions.
My point is not that the user is not happy, that they have to change permissions.
It is that the user would rather get a clear error message than to get two separate messages (warning that doesn't mention "ignore" and authentication error) they need to connect to understand what is going on.
> It's very similar to what ssh does
I'd say "ssh-add" is an example of the opposite behavior (error instead of warning):
- The command refuses to execute its main task: Adding the key.
- The command exits with code 1 - Failure
- The wording "will be ignored" is unfortunate, as it actually "has been ignored/rejected" - run "ssh-add -l" to confirm
I'd say "ssh-add" is an example of the opposite behavior (error instead of warning):
- The command refuses to execute its main task: Adding the key.
- The command exits with code 1 - Failure
- The wording "will be ignored" is unfortunate, as it actually "has been ignored/rejected" - run "ssh-add -l" to confirm
Postgres on the other hand:
- Continues with broken configuration
- Continues with broken configuration
- Exits due to collateral error
There is some nuance, since "ssh-add" will continue with other provided keys, but that is because they are entirely unrelated. It does clearly refuse the task and treat it as an error.
There is some nuance, since "ssh-add" will continue with other provided keys, but that is because they are entirely unrelated. It does clearly refuse the task and treat it as an error.
In effect, if you run "ssh-add ... && ssh ..." you will get an error because of the key permissions, not because of the authentication.
Am Fr., 5. Sept. 2025 um 20:02 Uhr schrieb Robert Haas <robertmhaas@gmail.com>:
On Thu, Sep 4, 2025 at 7:22 PM Paul Ohlhauser
<bendix.ohlhauser@gmail.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
pgsql-hackers by date: