Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uWneA-001bNA-G8 for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Jul 2025 02:56:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uWne8-009gcF-Gy for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Jul 2025 02:56:29 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uWne8-009gc3-4b for pgsql-hackers@lists.postgresql.org; Wed, 02 Jul 2025 02:56:28 +0000 Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uWne6-005DDL-2D for pgsql-hackers@lists.postgresql.org; Wed, 02 Jul 2025 02:56:28 +0000 Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-ae0dad3a179so1000602466b.1 for ; Tue, 01 Jul 2025 19:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751424986; x=1752029786; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=oS0XW/MJbixu3yXKxa16DFDBHS3Nhuew/qqTrQCbomo=; b=DOQtltudG90VwamwoEIPJ4UqDZ36apZO3+FtUCMyJ7aQX+hXROyuJuQqN3teB1990y j/gEfc/83nMVsHwpKLRUn8e4NXJW95ynWt2JgxgsJU+TsupS6Ng9CZZIL5Ne92IONF4s 9fcLYiqOTWTsDoy0KLtnxP1rdJFwlZVKWStOBlKjZvkYzqCTnprtHPOmfCTK7qMQ/xXI iQT5wJlr269tGUpYPZ4G4e8KlCD31EixNs2VJJPPyJY0UnZHRA64jfc3y+ZZbY4chMBg OUvUr015/L38/qNipLU4LRVbTwwbLHNpmED4xdQBlWADAZIjZxQxJFrMy5Djvzj5b4vG +bBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751424986; x=1752029786; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=oS0XW/MJbixu3yXKxa16DFDBHS3Nhuew/qqTrQCbomo=; b=nTqCz3DSLVXCJBFH9Rkor02AjOhYA8JRioiRe4YEgolvclqOfqtyChVU+R5ea73uYx Zpec2VR+4ZRE6IYAG3ykISswNS36imqXvlep9sqWjCkiobmqf15tw1NujUqijXFi0DR/ XiOX8urfS5iJGQiozK5EoMPYXxyAmaNrKcTPDP+N5tEsZZstHkryn4ackpmA8hUcS5BS 8y0s+Y3TX1Jk4KnVVEVgJwHVoO+wo6FWdcZzeX8/rZPSOQhU3oX/di/Nun1XgWCMmeZY bV+aLEfRImWm8kC1jMIcuXCcjcjvBVpyj0MqWpKZZ3pj6bWYq+IC6+7ybi1ebWgr0+FC FReA== X-Gm-Message-State: AOJu0YxsPVtgMadAVlaTLhVoeT/ELRLj//XJBm+l7lwP+3o+NxWspBmR ULAfET+vW00pYVwMAT36MKvF4Qmg6p1ReR2wpMFk2FAm8h5FEshl4MgcmMt7bqZmwpKtqI9Vky0 bQNMIvAp9Hlm5rxv0A2GSAXKtWP61Q2nnKDZGACaNJQ== X-Gm-Gg: ASbGnctij42XFLn6lvLZraxLCb98gP95K151k1T30O+T23TxzwsjKGuXvoWxXqQ+V2K VwLergw0JuXlMgSoDCZ9miNpZv4raFVO57hb0XMmpj5CeIPzuqySDlOxGoj+BdMDd+NR2/4SZn/ mhKqToDTufKcZr0TdkKqCl69k7g7IBewhPslgC5/Uu6PyMayt05QHCeUujGlZMn29AyrY/WbOQi O9h X-Google-Smtp-Source: AGHT+IHg8asXlUe2h9smmqlPdO2TyYGtptvKQdhaifTAMgQDJm5LbL7Z5BsIOmYo+dPvembmENzd0ZNCmR6TKflk8fY= X-Received: by 2002:a17:906:c14c:b0:ae3:bd96:78cd with SMTP id a640c23a62f3a-ae3c2a82095mr101678166b.7.1751424985549; Tue, 01 Jul 2025 19:56:25 -0700 (PDT) MIME-Version: 1.0 From: Jianghua Yang Date: Tue, 1 Jul 2025 19:55:49 -0700 X-Gm-Features: Ac12FXxQ7YorqbBkjAKwZE8J7S7KSKdgnf9GJKwmcT0DtMyxfouz93GDQy1En7k Message-ID: Subject: [PATCH] initdb: Treat empty -U argument as unset username To: pgsql-hackers@lists.postgresql.org Content-Type: multipart/mixed; boundary="0000000000001d81140638e96890" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000001d81140638e96890 Content-Type: multipart/alternative; boundary="0000000000001d81120638e9688e" --0000000000001d81120638e9688e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi hackers, While working with `initdb`, I noticed that passing an empty string to the `-U` option (e.g., `initdb -U ''`) causes it to fail with a misleading error: performing post-bootstrap initialization ... 2025-07-01 19:48:42.006 PDT [14888] FATAL: role """ does not exist at character 72 2025-07-01 19:48:42.006 PDT [14888] STATEMENT: UPDATE pg_class SET relacl =3D (SELECT array_agg(a.acl) FROM (SELECT E'=3Dr/""' as acl UNION SELECT unnest(pg_catalog.acldefault( CASE WHEN relkind =3D 'S' THEN 's' ELSE 'r' END::"char",10::oid)) ) as a) = WHERE relkind IN ('r', 'v', 'm', 'S') AND relacl IS NULL; This happens because `initdb` accepts the empty string as a valid role name and attempts to use it as the database superuser, which is not intended and fails during bootstrap SQL. I propose a small patch that treats an empty string passed to `-U` as if the option was not provided at all =E2=80=94 falling back to the current sy= stem user, which is the documented and expected behavior when `-U` is omitted. This change improves robustness and avoids confusing failure messages due to user input that is technically invalid but easy to produce (e.g., via scripting or argument quoting issues). ### Patch summary: - Checks if the passed `username` is non-null but empty (`'\0'`) - Replaces it with the effective system user in that case - Keeps the logic consistent with the existing behavior when `-U` is omitte= d Let me know if this approach seems reasonable or if you=E2=80=99d prefer we explicitly reject empty usernames with an error instead. Patch attached. Best regards, Jianghua Yang --0000000000001d81120638e9688e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi hackers,

While working with `initdb`, I noticed = that passing an empty string to the `-U` option (e.g., `initdb -U ''= ;`) causes it to fail with a misleading error:
=C2=A0 =C2=A0=C2=A0

performing post-bootstrap = initialization ... 2025-07-01 19:48:42.006 PDT [14888] FATAL:=C2=A0 role """ does no= t exist at character 72

2025-07-01 19:48:42.006 PD= T [14888] STATEMENT: =C2=A0

UPDATE pg_class =C2=A0 SET relacl =3D (SELECT array_ag= g(a.acl) FROM=C2=A0 (SEL= ECT E'=3Dr/""' as acl =C2=A0 UNION SELECT unnest(pg_catalog.acldefault(=C2=A0 =C2=A0 CASE WHEN relkind = =3D 'S' THEN 's'=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ELSE 'r' END::"char= ",10::oid)) ) as a) =C2=A0= WHERE relkind IN ('r', 'v', 'm', 'S'= ;)=C2=A0 AND relacl IS N= ULL;


This happens because `initdb` accepts the empty string a= s a valid role name and attempts to use it as the database superuser, which= is not intended and fails during bootstrap SQL.

I propose a small p= atch that treats an empty string passed to `-U` as if the option was not pr= ovided at all =E2=80=94 falling back to the current system user, which is t= he documented and expected behavior when `-U` is omitted.

This chang= e improves robustness and avoids confusing failure messages due to user inp= ut that is technically invalid but easy to produce (e.g., via scripting or = argument quoting issues).

### Patch summary:

- Checks if the = passed `username` is non-null but empty (`'\0'`)
- Replaces it w= ith the effective system user in that case
- Keeps the logic consistent = with the existing behavior when `-U` is omitted

Let me know if this = approach seems reasonable or if you=E2=80=99d prefer we explicitly reject e= mpty usernames with an error instead.

Patch attached.

Best re= gards, =C2=A0
Jianghua Yang=C2=A0=C2=A0
--0000000000001d81120638e9688e-- --0000000000001d81140638e96890 Content-Type: application/octet-stream; name="0001-initdb-Treat-empty-U-argument-as-unset-username.patch" Content-Disposition: attachment; filename="0001-initdb-Treat-empty-U-argument-as-unset-username.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mcld5wr20 RnJvbSAzOGMzNGRhYWFkMDU4MjVkNDEwMjdiOGY1OTYyNjU4YjNlZWU1MDdhIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBKaWFuZ2h1YSBZYW5nIDx5amhqc3R6QGdtYWlsLmNvbT4KRGF0 ZTogVHVlLCAxIEp1bCAyMDI1IDE5OjUyOjUyIC0wNzAwClN1YmplY3Q6IFtQQVRDSF0gaW5pdGRi OiBUcmVhdCBlbXB0eSAtVSBhcmd1bWVudCBhcyB1bnNldCB1c2VybmFtZQoKLS0tCiBzcmMvYmlu L2luaXRkYi9pbml0ZGIuYyB8IDIgKy0KIDEgZmlsZSBjaGFuZ2VkLCAxIGluc2VydGlvbigrKSwg MSBkZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL3NyYy9iaW4vaW5pdGRiL2luaXRkYi5jIGIvc3Jj L2Jpbi9pbml0ZGIvaW5pdGRiLmMKaW5kZXggNjJiYmQwOGQ5ZjYuLjJkZjE1OTk2MjcxIDEwMDY0 NAotLS0gYS9zcmMvYmluL2luaXRkYi9pbml0ZGIuYworKysgYi9zcmMvYmluL2luaXRkYi9pbml0 ZGIuYwpAQCAtMzQ3Miw3ICszNDcyLDcgQEAgbWFpbihpbnQgYXJnYywgY2hhciAqYXJndltdKQog CXNldHVwX2Jpbl9wYXRocyhhcmd2WzBdKTsKIAogCWVmZmVjdGl2ZV91c2VyID0gZ2V0X2lkKCk7 Ci0JaWYgKCF1c2VybmFtZSkKKwlpZiAoIXVzZXJuYW1lIHx8IHVzZXJuYW1lWzBdID09ICdcMCcp CiAJCXVzZXJuYW1lID0gZWZmZWN0aXZlX3VzZXI7CiAKIAlpZiAoc3RybmNtcCh1c2VybmFtZSwg InBnXyIsIDMpID09IDApCi0tIAoyLjM5LjUgKEFwcGxlIEdpdC0xNTQpCgo= --0000000000001d81140638e96890--