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 1rMJiE-003xOw-Dq for pgsql-docs@arkaria.postgresql.org; Sun, 07 Jan 2024 03:20:34 +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 1rMJiD-00DI2q-F2 for pgsql-docs@arkaria.postgresql.org; Sun, 07 Jan 2024 03:20:33 +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 1rMJiD-00DI2h-7S for pgsql-docs@lists.postgresql.org; Sun, 07 Jan 2024 03:20:33 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rMJi6-000FnU-EV for pgsql-docs@postgresql.org; Sun, 07 Jan 2024 03:20:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us; s=2023062407; h=In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-ID:Content-Description; bh=x+LMRfzQPWgAE55RZGVmButg5GQ4mKPalCrSVkV27PM=; b=ssFoNBE4hvpHOqpuvt3UYtdxl7 OY3rNwLXXwuX/p8kLsu5pNXH4BexbBaZvwSNPARUvpL20qsi/fWXqCwRtBn+f9VELqQSGud7M/QtH QN776NoXqjBB7RklNfiIN2AsOCLoDg3wKMuBBx9LC1SvezeoeYB2kkrQTezzzEgbRfw3wcCWKu335 5AEBGzMZXYbAhB5sxi2FDMiPFtet4KB5cN5IwseRBW4cGwU+CJdperAmJbB5kEpd7JOh/LnSOt1k2 1BmX1R5OttQOTheJT5P/XDHDfNnrPeqjmPTdXhYjHFiAzYNqx1NVbxTxohpeq9TRHSD7dsWRn7Ujp tNBSqzEg==; Received: from bruce by momjian.us with local (Exim 4.96) (envelope-from ) id 1rMJi4-008j45-0W; Sat, 06 Jan 2024 22:20:24 -0500 Date: Sat, 6 Jan 2024 22:20:24 -0500 From: Bruce Momjian To: "David G. Johnston" Cc: PostgreSQL-documentation , =?utf-8?Q?=C3=81lvaro?= Herrera Subject: Re: initdb username doc bug Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Jan 6, 2024 at 08:11:14PM -0700, David G. Johnston wrote: > On Saturday, January 6, 2024, Bruce Momjian wrote: > > This commit: > >         commit 910cab820d >         Author: Alvaro Herrera >         Date:   Fri Nov 18 11:59:26 2022 +0100 > >             Add glossary entries related to superusers > >             Extracted from a more ambitious patch. > >             Author: David G. Johnston >             Discussion: https://postgr.es/m/CAKFQuwZC4K0XYBm0bwBMDOZySBqhO > SekDhLuaw4vPi+ozi8gqQ@mail.gmail.com > > used this text for the --username option: > >        -U username >        --username=username >            Selects the user name of the bootstrap superuser. This defaults >            to the name of the cluster owner. > > This seems wrong since the cluster owner doesn't exist until the cluster > is created.  The text exists in PG 16 and master.  The attached patch > fixes this. > > > The glossary defines cluster owner as the pre-existing operating system user.  No, it does not. > There may be an argument that installation user is a better term but the > existing choice isn’t wrong.  If you are going to change it you need to update > the glossary as well.  The description in initdb uses cluster owner as well. > > I agree we presently use a mix of set and specify in these definitions so the > word choice of selects is out-of-place. The patch says: + + Cluster owner + + --> + The operating system user that owns the --> + data directory + and under which the postgres process is run. + It is required that this user exist prior to creating a new + database cluster. + + + On operating systems with a root user, + said user is not allowed to be the cluster owner. + + + How can you default to be the owner of something that doesn't exist before it is created? Also, the initdb code gets the default username from geteuid(), the effective process owner; man geteuid says: geteuid() returns the effective user ID of the calling process. so it is not the owner of the data dirctory, but the installation user. I am open to saying that it is the owner of the data directory but we would then need to change initdb to do that, and we aren't going to backpatch that. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.