[PG19-3 PATCH] Don't ignore passfile - Mailing list pgsql-hackers
| From | postgresql.cache976@passmail.net |
|---|---|
| Subject | [PG19-3 PATCH] Don't ignore passfile |
| Date | |
| Msg-id | 175693782874.7.4977774421995743377.886547785@passmail.net Whole thread Raw |
| Responses |
Re: [PG19-3 PATCH] Don't ignore passfile
Re: [PG19-3 PATCH] Don't ignore passfile |
| List | pgsql-hackers |
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
Attachment
pgsql-hackers by date: