Обсуждение: [PG19-3 PATCH] Don't ignore passfile
Hello everyone,
Thanks for taking the time to read the proposal.
If there are any additional steps required from me, please let me know explicitly as I am new to the process.
Kind regards
Paul Ohlhauser
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 but has open permissions, postgres issues the following warning:
> "WARNING: password file \"%s\" has group or world access; permissions should be u=rw (0600) or less\n"
in /src/interfaces/libpq/fe-connect.c:7999
The warning informs the user, that the "passfile" potentially exposes the password to other system users (how nice!).
The warning doesn't inform the user that it ignores the "passfile" and continues without it.
The check was added somewhat hastily here 23 years ago: https://github.com/postgres/postgres/commit/40f2eec503237b34854c2249a4b6182c4f4800e2
## Issues
### Fundamental
- The current behaviour does not fulfill the users intention or expectations in any case:
- The user specified the "passfile" to be used. Postgres ignores it instead.
- If the user really doesn't want the process to use a potentially insecure "passfile", they probably want to see an error right away. Postgres runs with an incomplete configuration instead, leading to authentication issues later on.
### Peripheral
- The warning does not inform the user, that the "passfile" is being ignored (people in IRC#postgresql felt the same).
- The check is not present in Windows, so the behavior is completely different there.
- The check does not follow symlinks to check the actual file permissions.
- The check is inconsistent with the private key file check at /src/backend/libpq/be-secure-common.c:171 which permits group read access.
- Group read access is needed / useful in certain scenarios (e.g. Kubernetes fsGroup)
## Solutions
### Preferred (the submitted patch)
Postgres should just warn the user about the potentially insecure configuration, but carry on with the provided configuration as-is.
The user is responsible for storing the password securely.
A quick check and warning by postgres is nice to have, but ultimately there are endless ways for the user to insecurely store the password that postgres does not detect (e.g. symlink, Windows). Currently postgres rejects secure uses of "passfile" (e.g. group read) and potentially pushes users in environments with restricted configuration options into a less secure configuration (e.g. storing the password in plain text in a configuration file using the "password" directive instead i.e. no separation of config & password).
### Alternative solutions
- Postgres should inform the user that the "passfile" is ignored.
- This is the bare minimum in my opinion
- Incompatible with the preferred solution
- As stated above, ignoring the "passfile" is not desirable
- Postgres should make this an error instead.
- Incompatible with the solutions above
- Opposite of the suggested solution, but at least clear. Some users would probably be happy with it
- Breaking change in setups with ignored "passfile" (edge-case, not likely)
- Very inconsistent (see peripheral issues above)
- Postgres should allow group read permissions.
- This is compatible with all solutions listed above
- I did not include this change to keep the patch simple
- Patching this requires changing the translations (they can probably/partially be copied from the private key file permission check)
Thanks for taking the time to read the proposal.
If there are any additional steps required from me, please let me know explicitly as I am new to the process.
Kind regards
Paul Ohlhauser
Вложения
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 this by a command such as chmod 0600 ~/.pgpass. If the permissions are less strict than this, the file will be ignored. On Microsoft Windows, it is assumed that the file is stored in a directory that is secure, so no special permissions check is made." Maybe it should be highlighted in documentation as a *Note* to put some more emphasis? [1] https://www.postgresql.org/docs/current/libpq-pgpass.html -- Umar Hayat SKAI Worldwide (https://skaiworldwide.com/)
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 eventually look at the documentation, but the behavior is not self-explanatory nor intuitive (even though it could be). Reality is, that most users do not read the documentation for each directive they use to the very end. As libpg is used in many other software products, users consulting the Postgres documentation specifically is less common. I really don't want to defend the user potentially being negligent - I am saying that the current behavior has no/minimal use and could be more intuitive to spare users time.
- The warning itself does not indicate that the "passfile" is ignored. Of course users can and hopefully will eventually look at the documentation, but the behavior is not self-explanatory nor intuitive (even though it could be). Reality is, that most users do not read the documentation for each directive they use to the very end. As libpg is used in many other software products, users consulting the Postgres documentation specifically is less common. I really don't want to defend the user potentially being negligent - I am saying that the current behavior has no/minimal use and could be more intuitive to spare users time.
- While the documentation addresses one or two peripheral issues I mentioned, it does not address the fundamental issue, that the current behavior is not useful / in the users interest.
- Not being able to use group permissions is also still a prohibitive constraint.
I'll also include the gist of the patch here as it is a 2-3 line change:
- fclose(fp);
- return NULL;
I'll also include the gist of the patch here as it is a 2-3 line change:
- fclose(fp);
- return NULL;
Kind regards
Paul Ohlhauser
PS: I changed my email address in the mailing list, hope that's not an issue.
postgresql.cache976@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
arguments in favor of it are pretty thin.
I will concede your point that the error message isn't really clear
that we're ignoring the passfile, but that could be addressed
simply by rephrasing the message, perhaps like
"WARNING: password file \"%s\" was ignored because it allows group or world access; permissions must be u=rw (0600) or
less\n"
Another idea could be to fail the connection instead of treating this
as a warning condition. But I imagine that if the passfile would
actually be used, the connection would fail anyway.
> - The check does not follow symlinks to check the actual file permissions.
Really? It's based on fstat which is going to check the
actually-opened file.
> - The check is inconsistent with the private key file check at /src/backend/libpq/be-secure-common.c:171 which
permitsgroup read access.
We could certainly have a discussion about whether the scenario being
catered to there (a root-owned file that we have group access to)
is sensible for password files. I kind of doubt it but maybe I'm
missing something. Note that fe-secure-openssl.c would be a better
reference point for code that is executing on the client side.
In general I'm open to carefully-thought-out improvements to this
check. But "we don't need to enforce this at all" isn't going to
happen.
regards, tom lane
PS: please use an email agent that provides References: headers in
replies, else this conversation will be impossible to follow in our
mail archives (or many people's mail readers). I see that your
response to Umar is already a disconnected thread.
> It flies in the face of security concerns, and your arguments in favor of it are pretty thin.
> We could certainly have a discussion about whether the scenario being catered to there (a root-owned file that we have group access to) is sensible for password files.
In Kubernetes, when setting "defaultMode: 0400" and "securityContext.fsGroup: 2000" to mount a file for example you end up with the minimal permissions on the mounted file:
-r--r----- 1 root 2000 90 Sep 1 14:42 password
This is just one example use case, I'd imaging others can think of more.
Maybe someone is running a database server and client application with separate users on a system and symlinks the passfile or references it by path to have a single source of truth.
> In general I'm open to carefully-thought-out improvements to this check
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.
Kind regards
Paul Ohlhauser
PS:
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 actually-opened file.
My bad, I was testing with group read permission, before realizing that those aren't allowed either.
> 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)
> But I imagine that if the passfile would actually be used, the connection would fail anyway.
I'm not sure I am following. Yes, the authentication doesn't work without the passfile, but error cause message and error effect messages are disconnected in the logs.
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)
> But I imagine that if the passfile would actually be used, the connection would fail anyway.
I'm not sure I am following. Yes, the authentication doesn't work without the passfile, but error cause message and error effect messages are disconnected in the logs.
> We could certainly have a discussion about whether the scenario being catered to there (a root-owned file that we have group access to) is sensible for password files.
In Kubernetes, when setting "defaultMode: 0400" and "securityContext.fsGroup: 2000" to mount a file for example you end up with the minimal permissions on the mounted file:
-r--r----- 1 root 2000 90 Sep 1 14:42 password
This is just one example use case, I'd imaging others can think of more.
Maybe someone is running a database server and client application with separate users on a system and symlinks the passfile or references it by path to have a single source of truth.
> In general I'm open to carefully-thought-out improvements to this check
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.
Kind regards
Paul Ohlhauser
PS:
> please use an email agent that provides References
Sorry I switched email addresses after my first mail and hoped it would connect the thread.
I wont be switching addresses again any time soon
I wont be switching addresses again any time soon
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 canthink 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 professionalC 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
> 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
On Sat, Sep 6, 2025 at 9:52 AM Paul Ohlhauser <bendix.ohlhauser@gmail.com> 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 error) they need to connect to understand what is going on. 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. -- Robert Haas EDB: http://www.enterprisedb.com
> 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:
I see three problems:
- A.) Postgres unintuitively continues with a broken configuration
- B.) Postgres does not at least inform the user that the passfile is ignored
- C.) Group permissions are not allowed
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,B,C)
Option 4 is the easiest and the patch I submitted but does not seem to be well received
Option 1 is the bare minimum IMO - it's still not great though
I'd like to see options 2 & 3 (same behavior as SSH)
> 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:
I see three problems:
- A.) Postgres unintuitively continues with a broken configuration
- B.) Postgres does not at least inform the user that the passfile is ignored
- C.) Group permissions are not allowed
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,B,C)
Option 4 is the easiest and the patch I submitted but does not seem to be well received
Option 1 is the bare minimum IMO - it's still not great though
I'd like to see options 2 & 3 (same behavior as SSH)
Am Mo., 8. Sept. 2025 um 15:36 Uhr schrieb Robert Haas <robertmhaas@gmail.com>:
On Sat, Sep 6, 2025 at 9:52 AM Paul Ohlhauser
<bendix.ohlhauser@gmail.com> 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 error) they need to connect to understand what is going on.
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.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Sep 8, 2025 at 11:20 AM Paul Ohlhauser <bendix.ohlhauser@gmail.com> 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,B,C) > > Option 4 is the easiest and the patch I submitted but does not seem to be well received > Option 1 is the bare minimum IMO - it's still not great though > I'd like to see options 2 & 3 (same behavior as SSH) 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. 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. I don't really know what I think about allowing group permissions. It's reasonable in the sense that we have an option to allow that for $PGDATA, but OTOH we have no real understanding of Windows permissions or Linux ACLs or SELinux security constraints, so that idea that we can force "safe" permissions is a little bit laughable. -- Robert Haas EDB: http://www.enterprisedb.com
Robert Haas <robertmhaas@gmail.com> 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.
> 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 don't really know what I think about allowing group permissions.
> It's reasonable in the sense that we have an option to allow that for
> $PGDATA, but OTOH we have no real understanding of Windows permissions
> or Linux ACLs or SELinux security constraints, so that idea that we
> can force "safe" permissions is a little bit laughable.
As I recall, at the time this code was added, it was not at all
unusual for systems to be set up with all users being members of
a group named "users" or so, and even for that to be the default
group for new files, so that granting group read was not a lot
tighter than granting world read. It looks like macOS and Solaris
at least are still that way --- they call the group "staff" not
"users", but the problem is the same. NetBSD uses "users"; I did
not check other BSDen. But it sure looks like "group per user
by default" may be a Linux-ism.
So I'm pretty down on allowing group read here, at least as a default
behavior. Maybe there could be some kind of option to allow it,
but again I'd like more than one request per quarter-century before
we go to the trouble. (I note also that the holes we've poked for
group access to $PGDATA and SSL key files were poked in response to
extremely concrete, hard-to-work-around use-cases, which is something
I'm not hearing here.)
regards, tom lane
On Mon, Sep 8, 2025 at 10:46 AM Tom Lane <tgl@sss.pgh.pa.us> 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 direction of "error rather than warning", personally... Not a real vote yet; I'm not sure I understand the compatibility fallout. Like, who would be angry if we did that? No opinion on group read. But we should absolutely clarify the warning message. --Jacob
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 mailing list to report a minor UX issue.
> As I recall, at the time this code was added, it was not at all
> unusual for systems to be set up with all users being members of
> a group named "users" or so, and even for that to be the default
> group for new files, so that granting group read was not a lot
> tighter than granting world read.
Does this include files created by root?
The usual way (again, same as SSH) is to only allow group permissions if the file is owned by root.
This ensures that using group permissions was an intentional choice and not an accident.
As mentioned before, Postgres is already doing this check for other files (see: /src/interfaces/libpq/fe-secure-openssl.c:1269)
"private key file \"%s\" has group or world access; file must have permissions u=rw (0600) or less if owned by the current user, or permissions u=rw,g=r (0640) or less if owned by root"
> [...], so that idea that we can force "safe" permissions is a little bit laughable.
Users can always store the password insecurely. Alerting about easy-to-detect issues is nice of course, but there's no protection against things like:
# Provide connection info
cat > start.sh <<EOF
export PGPASSWORD="mypass"
./actual-postgres-app
EOF
chmod 777 start.sh # Make my script executable
Might be a ridiculous example, but maybe more likely than somebody running Postgres on macOS using a mis-secured passfile (owned by root with group staff or similar) with multiple users.
In my very particular case the restrictions imposed force me to put the password in the configuration file somehow (plain, via templating script, helm --set, etc.) as I cannot mount with permissions below 0440 (k8s fsGroup) and cannot use environment variables (particular helm chart).
Using passfile with group permissions would be a more straight forward way to set the password securely here.
For reference: homeserverConfig.database.args.password in https://github.com/remram44/matrix-helm/blob/master/charts/matrix/values.yaml
I'm not looking to resolve this particular case (I already use helm --set), just mentioning it as an example use-case for anyone interested.
Yes this is a niche issue, as most people using containers use PGPASSWORD and most people not using containers don't care about groups on the passfile.
It is possible to work around it and the barrier to reporting issues to Postgres is higher then "thumps up on GitHub issue" as with many other open source projects, so not many people will complain.
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 mailing list to report a minor UX issue.
> As I recall, at the time this code was added, it was not at all
> unusual for systems to be set up with all users being members of
> a group named "users" or so, and even for that to be the default
> group for new files, so that granting group read was not a lot
> tighter than granting world read.
Does this include files created by root?
The usual way (again, same as SSH) is to only allow group permissions if the file is owned by root.
This ensures that using group permissions was an intentional choice and not an accident.
As mentioned before, Postgres is already doing this check for other files (see: /src/interfaces/libpq/fe-secure-openssl.c:1269)
"private key file \"%s\" has group or world access; file must have permissions u=rw (0600) or less if owned by the current user, or permissions u=rw,g=r (0640) or less if owned by root"
> [...], so that idea that we can force "safe" permissions is a little bit laughable.
Users can always store the password insecurely. Alerting about easy-to-detect issues is nice of course, but there's no protection against things like:
# Provide connection info
cat > start.sh <<EOF
export PGPASSWORD="mypass"
./actual-postgres-app
EOF
chmod 777 start.sh # Make my script executable
Might be a ridiculous example, but maybe more likely than somebody running Postgres on macOS using a mis-secured passfile (owned by root with group staff or similar) with multiple users.
In my very particular case the restrictions imposed force me to put the password in the configuration file somehow (plain, via templating script, helm --set, etc.) as I cannot mount with permissions below 0440 (k8s fsGroup) and cannot use environment variables (particular helm chart).
Using passfile with group permissions would be a more straight forward way to set the password securely here.
For reference: homeserverConfig.database.args.password in https://github.com/remram44/matrix-helm/blob/master/charts/matrix/values.yaml
I'm not looking to resolve this particular case (I already use helm --set), just mentioning it as an example use-case for anyone interested.
Yes this is a niche issue, as most people using containers use PGPASSWORD and most people not using containers don't care about groups on the passfile.
It is possible to work around it and the barrier to reporting issues to Postgres is higher then "thumps up on GitHub issue" as with many other open source projects, so not many people will complain.
> 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 the open passfile in-place and found another way to provide the password that Postgres was happy with.
> [...], so that idea that we can force "safe" permissions is a little bit laughable.
Another slightly ridiculous example above: A user may leave the vulnerable passfile in place, ignore the warning and provide the password other way.
The error would ensure they need to clean their passfile up.
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 the open passfile in-place and found another way to provide the password that Postgres was happy with.
> [...], so that idea that we can force "safe" permissions is a little bit laughable.
Another slightly ridiculous example above: A user may leave the vulnerable passfile in place, ignore the warning and provide the password other way.
The error would ensure they need to clean their passfile up.