Great to see some consensus on the warning message at least.
I get that this is a niche issue and that it may not be a priority to make
a medium-sized change as changing from a warning to an error would be.
Regarding demand: Keep in mind that basically nobody will create an account
and join a mail
Robert Haas writes:
> I think clarifying the warning is probably an acceptable change as
> long as the new wording is equally clear and doesn't add much to the
> length of the message. Of course, I don't have the only vote here.
It's totally fair to say that this message needs clarification.
> C
On Sat, Sep 6, 2025 at 9:52 AM Paul Ohlhauser
wrote:
> 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
>
> I'm not sure I understand the compatibility fallout. Like, who would be
angry if we did that?
>From my very first message:
> Breaking change in setups with ignored "passfile" (edge-case, not likely)
So unless I am missing something this only affects people who ran into a
permission issue, left
On Mon, Sep 8, 2025 at 10:46 AM Tom Lane wrote:
> > Changing the warning to an error wouldn't bother me a great deal, but
> > we'd probably need more than just you voting for that alternative to
> > justify overturning longstanding behavior.
>
> Agreed.
I think I'm starting to lean in the directi
On Mon, Sep 8, 2025 at 11:20 AM Paul Ohlhauser
wrote:
> And I propose one or more of the following solutions:
> - 1. Make the warning clearer by stating that passfile is ignored (B)
> - 2. Change the warning to be an error (A,B)
> - 3. Allow group permissions (C)
> - 4. Just warn, don't ignore (A,
> Would it address your concern if we reworded that error message to be
> more clear that the file is going to be ignored? I think that proposal
> would have a better chance of success than this one.
Yes, that would improve it a bit. I already suggested this in my very first
message.
To reiterate:
Hi,
I haven't reviewed your patch, Not sure what would be expected
behaviour but the current one is documented in PostgreSQL
documentation [1], so there should not be any surprises for users.
"On Unix systems, the permissions on a password file must disallow any
access to world or group; achieve th
> 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
On Thu, Sep 4, 2025 at 7:22 PM Paul Ohlhauser
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
> It flies in the face of security concerns, and your arguments in favor
of it are pretty thin.
To me the existing check looked pretty lose and I am probably not fully
aware of the security constraints here, hence the suggested patch.
> Really? It's based on fstat which is going to check the act
postgresql.cache...@passmail.net writes:
> The small patch (against postgres:master for PG19-3) changes postgres to
> permit "passfile"s with open permissions.
I think the odds that we'd accept this change are not distinguishable
from zero. It flies in the face of security concerns, and your
arg
Hi Umar,
thanks for taking a look and pointing to the documentation.
While it is good that this behavior is noted in the documentation, the
issues mentioned in my proposal still stand:
- The warning itself does not indicate that the "passfile" is ignored. Of
course users can and hopefully will ev
Hello everyone,
This is my first patch! I tried my best to follow the patch submission guides.
The small patch (against postgres:master for PG19-3) changes postgres to permit
"passfile"s with open permissions.
I'll do my best to explain my reasoning:
## Context
When a "passfile" is configured bu
14 matches
Mail list logo
