On Thu, Sep 4, 2025 at 7:22 PM Paul Ohlhauser <bendix.ohlhau...@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
