public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jianghua Yang <[email protected]>
To: Tom Lane <[email protected]>
To: [email protected]
Subject: Re: [PATCH] initdb: Treat empty -U argument as unset username
Date: Fri, 20 Mar 2026 06:32:46 -0700
Message-ID: <CAAZLFmTiZXD3U8Wdu=3WugpoLfgqP1FX=9QinEwiMmvE3GRXPg@mail.gmail.com> (raw)
In-Reply-To: <CAAZLFmSw8wnYo3DYsynEH-Otr0UKQNfeQRoRQzDMmwt0A36kcQ@mail.gmail.com>
References: <CAAZLFmRK+XFp=mqCeruyNVkqGq5mH45CP+e-8oNttPRtLuB5eQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAAZLFmTtupwxA33fxVQ69AXG03RjXcoiEmd2soNSAk=Gc4ADkg@mail.gmail.com>
<[email protected]>
<CAAZLFmSw8wnYo3DYsynEH-Otr0UKQNfeQRoRQzDMmwt0A36kcQ@mail.gmail.com>
Hi,
The underlying aclitem quoting issue has been fixed in commit 64840e46243
("Fix inconsistent quoting of role names in ACLs"), so the concern about
this patch interfering with that investigation no longer applies.
Here's a rebased version of the patch. The approach is unchanged from v3:
reject an empty string passed to -U/--username early with a clear error
message, rather than letting it fall through to a confusing FATAL during
bootstrap SQL execution.
Changes:
- Add an empty-string check before the existing pg_ prefix check
in initdb's main(), using pg_fatal().
- Add a regression test using command_fails_like() to verify the
error message.
Jianghua Yang <[email protected]> 于2025年7月5日周六 10:45写道:
> Hi Tom,
>
> Thanks for the clarification.
>
> Just to provide a bit more context — we encountered this issue in a
> production environment where initdb was being run inside a Docker
> container. In such environments, the $USER environment variable may be
> unset or empty, which causes initdb -U $USER to fail with a confusing
> error.
>
> While it's true that this behavior has existed for a long time, it's
> become more relevant as Docker and containerized deployments have become
> common. This issue can be hard to diagnose for users unfamiliar with the
> internals of initdb, especially since the failure message isn't very
> informative in this case.
>
> I understand your point about not wanting to merge the patch prematurely
> if it could obscure underlying problems. That said, this particular fix
> seems orthogonal to the ACL parsing issue and addresses a real-world
> usability problem with minimal risk.
>
> Would you be open to reconsidering a standalone merge of this patch, or
> perhaps applying a minimal workaround for cases where $USER is unset?
>
> Thanks again for your time and consideration.
>
> Best regards,
> Jianghua Yang
>
> Tom Lane <[email protected]> 于2025年7月5日周六 10:34写道:
>
>> Jianghua Yang <[email protected]> writes:
>> > I wanted to ask if this patch can be merged first, as it seems to be a
>> > separate issue different from the aclitem parsing problem Tom discussed
>> in
>> >
>> https://www.postgresql.org/message-id/3792884.1751492172%40sss.pgh.pa.us
>>
>> Merging your patch will make it more difficult to poke at these
>> underlying issues, so I'm not in a hurry to do that. It's not
>> like this is an urgent issue: initdb has behaved like that for
>> years if not decades, and nobody's complained before.
>>
>> regards, tom lane
>>
>
Attachments:
[application/octet-stream] 0001-initdb-reject-empty-string-for-U-username-option.patch (1.8K, 3-0001-initdb-reject-empty-string-for-U-username-option.patch)
download | inline diff:
From e062dc164da02619f0716fa78ff0f9e422490c65 Mon Sep 17 00:00:00 2001
From: Jianghua Yang <[email protected]>
Date: Fri, 20 Mar 2026 06:30:03 -0700
Subject: [PATCH] initdb: reject empty string for -U/--username option
Previously, passing an empty string to initdb's -U option (e.g.,
initdb -U '') was accepted without complaint, but later caused a
confusing FATAL error during bootstrap SQL execution.
Add an explicit check for an empty superuser name before the existing
pg_ prefix validation, so that the user gets a clear error message
upfront.
Discussion: https://postgr.es/m/[email protected]
---
src/bin/initdb/initdb.c | 3 +++
src/bin/initdb/t/001_initdb.pl | 3 +++
2 files changed, 6 insertions(+)
diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c
index 509f1114ef6..25cd398cc6c 100644
--- a/src/bin/initdb/initdb.c
+++ b/src/bin/initdb/initdb.c
@@ -3500,6 +3500,9 @@ main(int argc, char *argv[])
if (!username)
username = effective_user;
+ if (username[0] == '\0')
+ pg_fatal("superuser name must not be empty");
+
if (strncmp(username, "pg_", 3) == 0)
pg_fatal("superuser name \"%s\" is disallowed; role names cannot begin with \"pg_\"", username);
diff --git a/src/bin/initdb/t/001_initdb.pl b/src/bin/initdb/t/001_initdb.pl
index 081535a22e4..8c54461fe98 100644
--- a/src/bin/initdb/t/001_initdb.pl
+++ b/src/bin/initdb/t/001_initdb.pl
@@ -34,6 +34,9 @@ command_fails(
[ 'initdb', '--waldir' => 'pgxlog', $datadir ],
'relative xlog directory not allowed');
+command_fails_like([ 'initdb', '--username' => '', $datadir ],
+ qr/superuser name must not be empty/,
+ 'empty username not allowed');
command_fails([ 'initdb', '--username' => 'pg_test', $datadir ],
'role names cannot begin with "pg_"');
--
2.50.1 (Apple Git-155)
view thread (16+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: [PATCH] initdb: Treat empty -U argument as unset username
In-Reply-To: <CAAZLFmTiZXD3U8Wdu=3WugpoLfgqP1FX=9QinEwiMmvE3GRXPg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox