pgconn: os/user.Current is called even when user is explicitly configured, causing SIGFPE in distroless containers

[tobyguelly]

Describe the bug
pgconn.ParseConfigWithOptions appears to call defaultSettings() before parsing and merging the connection string. defaultSettings() calls os/user.Current() to populate the default PostgreSQL user / passfile / servicefile.

This means os/user.Current() is called even when the connection string explicitly contains user=....

In minimal/distroless container environments this can crash during CGO user lookup before the provided PostgreSQL user is applied.

To Reproduce
Call pgconn.ParseConfigWithOptions within a distroless Docker container with CGO enabled which will subsequently use the crashing libc implementation of user.Current().

Expected behavior
If the connection string or environment explicitly provides user, pgx should not need to call os/user.Current() to determine a default user.

Ideally, user lookup would be lazy / conditional:

• parse connection string
• parse environment
• merge provided settings
• only call os/user.Current() if user, passfile, or servicefile defaults are actually needed

Actual behavior
pgx eagerly looks up default OS-user-derived information even when that information is not needed, because the PostgreSQL user has already been explicitly configured. The crash is the visible symptom, but the pgx behavior concern is the unnecessary eager lookup of default information before knowing whether those defaults are required.

Stack trace excerpt:

SIGFPE: floating-point exception
signal arrived during cgo execution

os/user._Cfunc_mygetpwuid_r(...)
os/user.lookupUnixUid(...)
os/user.current()
os/user.Current()

github.com/jackc/pgx/v5/pgconn.defaultSettings()
github.com/jackc/pgx/v5/pgconn.ParseConfigWithOptions(...)

Version

• Go: go1.26.4 linux/amd64
• pgx: v5.10.0
• Go build uses CGO, so os/user.Current() uses the libc lookup

Additional context
Any of these workarounds avoids or mitigates the issue:

• build with -tags osusergo
• build with CGO_ENABLED=0, if possible

[jackc]

The issue is broader than just finding the OS user name as the default name for the PG user. It is also used to get the home directory which is used for ~/.pgpass, ~/.pg_service.conf, ~/.postgresql/postgresql.crt, ~/.postgresql/postgresql.key, and ~/.root.crt. It seems that call would be needed regardless of whether the PG user is provided some other way.

Does libpq work in your container? As far as I can tell, it uses the equivalent of os/user.Current() to get the home directory.

In theory, we could use $HOME instead of os/user.Current(), but I'm not eager to diverge from libpq behavior even if $HOME and os/user.Current() should typically yield the same results.