Re: [PG19-3 PATCH] Don't ignore passfile

From: Paul Ohlhauser <bendix(dot)ohlhauser(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: postgresql(dot)cache976(at)passmail(dot)net, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PG19-3 PATCH] Don't ignore passfile
Date: 2025-09-04 23:22:19
Message-ID: CAGbOXJF-Fks-X2MC-8qorWUDP-xN4jAeaCsPD-wcQ0eXka30sw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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 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.

> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mihail Nikalayeu 2025-09-05 00:25:56 Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements
Previous Message Michael Paquier 2025-09-04 23:10:00 Re: Refactoring: Use soft error reporting for *_opt_error functions