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 1ubJ0w-00GSLN-2n for pgsql-general@arkaria.postgresql.org; Mon, 14 Jul 2025 13:14:38 +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 1ubJ0u-007i7o-71 for pgsql-general@arkaria.postgresql.org; Mon, 14 Jul 2025 13:14:36 +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 1ubIpM-007UU4-8n for pgsql-general@lists.postgresql.org; Mon, 14 Jul 2025 13:02:40 +0000 Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ubIpK-007bgH-29 for pgsql-general@lists.postgresql.org; Mon, 14 Jul 2025 13:02:40 +0000 Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-3a6d1369d4eso2429477f8f.2 for ; Mon, 14 Jul 2025 06:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752498156; x=1753102956; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=f8Un9rVXvrtr3BOhrPXogEdMen/ZhlSqWKX15u6tetM=; b=X7LPenO9vJ56qVKMPFUmxfuIQ4MelALDJvcpxcXLsbWBTg5k6UNpJPUhlmjmnichMa ilXDEy85CW/qj0S2xVmaC8liajYMqQ1XlloRT778VabFEOCOShiYbSezisU8ZECuLQ2T mCb344hI5NP0AT2dTC/XFiPFpSlaJrNKVr9ft/TaI9ANjd9gbUST1McpNfkv0BtHQvaW GXIOgU50sehtxLAojLEHq2wYImScQFeml2dByo07TFjAdHeyHaamiG9XYZKE2wLDbXVu IqmmpOVB4VflCwQlt9aLl53k8fG6zrqMInfWB0L5bMfkeoqldl7VRgFB2NTnGKnGezLn aKiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752498156; x=1753102956; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=f8Un9rVXvrtr3BOhrPXogEdMen/ZhlSqWKX15u6tetM=; b=Sut/oiDR/LIfuPlWRtvDDaJW93cjIYtLel7mNnSclPtjtN0jmcyM8Db5z8PpKF/hKZ uHa/NzFTKvFRfXIqMVSSwMcaw43ocd5J+uN1yaYe9NAE1BYpwGAQ531w/zKm0c0g/ZIa 5I2u5vyE9+skyQzlTIG+v1HGhx0AcRERGHcRKXhnPYd2ozeEq+c+LxwyArJYyrcQfF4m p7CH93Mb3gYVb9caT9vTXVYQ+l5+3rCHGDtjj2iG1V19+9OKU7fwlZU7i/qpYbLfDSvE slhUCo1TTAUhX4TaaLEthyoFFFKoh62dWm3jI/xr9km9ooENrlFngqCdVVjvDBW0EcU1 /WNw== X-Gm-Message-State: AOJu0Yz7XfVo8UWaN5atXEtWE6lULuJqlEB9I8amuvW9qoe7V+r+jkyN IEuxyaJ+b73g1+mb8PyNk989iGGSBISs0rwuUTRIjDqxhydpcQXWjPaL5XRebX0t4Aed3pMEPWm DgTMCpF6Tw9PvHZL9QyhQvUxY00NTIak= X-Gm-Gg: ASbGncvUYqCbp0zVL4P1iOWSQ0iwcqlfmDGk65OfYQwvySyDOwSP+pK29rK6oC7P2Ih VPlh66eUDxgJ7gZbCSOcfLRlzRwZJtGfJKWdZ/K2LGhrSl4NMsNkMvD5PUkJQ2JMIBwzwzQ5Q/D aUdWI3cBTnP1GPj8jn1gP6Txl8+Nw1FH2oobJeRdOQTI+dM3XE45AQ9TSLr6mboAsytGP2Uhohf D05C7JVpYKlno2KXTfgqsRZYA4G3yyjvsTdXZhb X-Google-Smtp-Source: AGHT+IGdda519eGPNDpW58CAkPDY08q2RYb9TPHCGNi7G3XMx/EYEee+Xp2ui7hxqh5I53Ceehudqo+DlL8qErmLbQA= X-Received: by 2002:a05:6000:43c9:b0:3a6:d95e:f38c with SMTP id ffacd0b85a97d-3b5f3578331mr6307498f8f.33.1752498155273; Mon, 14 Jul 2025 06:02:35 -0700 (PDT) MIME-Version: 1.0 References: <13e3100fc7c7d14919c37943dcfd76b263cecce2.camel@cybertec.at> <0b3fb11184bf9ce6516ed1aa08af5dddc924f21c.camel@cybertec.at> In-Reply-To: <0b3fb11184bf9ce6516ed1aa08af5dddc924f21c.camel@cybertec.at> From: Amol Inamdar Date: Mon, 14 Jul 2025 18:32:23 +0530 X-Gm-Features: Ac12FXwQi6bU-UnvS07xy6ioc-f7gn9gkta3Dzz8U9_NCxC0j0b60Ewbd0-HtyI Message-ID: Subject: Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS) To: Laurenz Albe Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000003c7ee0639e34668" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000003c7ee0639e34668 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Laurenz, The data directory can either be created by "initdb", in which case the mount point must allow the PostgreSQL user to create a directory. You could set the group of the mount point to the group of the PostgreSQL user and use permissions 1770, which should be perfectly safe. This exactly is the problem we are facing, to give you a summary, our NFS server is enabled with AT-TLS authentication and we are accessing the server via a proxy server (Haproxy). This acts as our NFS client and it is configured with the required client certificates. The outcome of above configuration is that any directory created in the NFS mount is always owned by the user in the certificates and if that user isn't present in the proxy container it is marked as nobody:nogroup, we tried various things like created the user similar to postgres user so that the users ids match but always ended up giving error =E2=80=9Cdata directory =E2=80=9C/var/lib=E2= =80=9D has wrong ownership Hence, we thought of skipping this check (Directory owner and postgres user validation) and wanted to understand the implication of the same. Thanks, Amol, On Mon, Jul 14, 2025 at 6:14=E2=80=AFPM Laurenz Albe wrote: > On Mon, 2025-07-14 at 17:59 +0530, Amol Inamdar wrote: > > If I am not mistaken, below is my understanding of your suggestion. > > > > Suppose that My mount point on the NFS server is say > /nfs-mount/postgres/ > > and you are suggesting to have a data directory as say > /nfs-mount/postgres/db or something like that ? > > and assign this value to the PGDATA ? > > > > If that is the case, then when and who should be creating the directory > DB ? > > > > Please correct me if I am wrong about the understanding. > > You understood me perfectly well. > > The data directory can either be created by "initdb", in which case > the mount point must allow the PostgreSQL user to create a directory. > You could set the group of the mount point to the group of the > PostgreSQL user and use permissions 1770, which should be perfectly safe. > > Alternatively, the root user could create the data directory with the > correct ownership and permissions prior to running "initdb". > > Yours, > Laurenz Albe > --=20 -regards Amol --00000000000003c7ee0639e34668 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Laurenz,=C2=A0

= The data directory can either be created by "i= nitdb", in which case
the mount point must allow the PostgreSQL use= r to create a directory.
You could set the group of the mount point to t= he group of the
PostgreSQL user and use permissions 1770, which should b= e perfectly safe.

This exactly is the probl= em we are facing, to give you a summary,=C2=A0
our NFS server is = enabled with AT-TLS authentication
and we are accessing the serve= r via a proxy server (Haproxy).=C2=A0
This acts as our NFS client= and it is configured with the=C2=A0
required client certificates= .

The outcome of above configuration is that any d= irectory created=C2=A0
in the NFS mount is always owned by the us= er in the certificates=C2=A0
and if that user isn't present i= n the proxy container it is marked=C2=A0
as nobody:nogroup, we tr= ied various things like
created the user similar to postgres user= so that the users ids match but=C2=A0
always ended up giving err= or=C2=A0=C2=A0=E2=80=9Cdata directory =E2=80=9C/var/lib=E2=80=9D has= wrong ownership=C2=A0

Hence, we thought of= skipping this check (Directory owner and postgres user validation) and=C2= =A0
wanted to understand the implication of the same.=C2=A0
=

Thanks,
Amol,



On Mon, Jul 14, 2025 at 6:14=E2=80=AFPM Laurenz A= lbe <laurenz.albe@cybertec.a= t> wrote:
On Mon, 2025-07-14 at 17:59 +0530, Amol Inamdar wrote:
> If I am not mistaken, below is my understanding of your suggestion.=C2= =A0
>
> Suppose that My mount point on the NFS server is say /nfs-mount/postgr= es/=C2=A0
> and you are suggesting to have a data directory as say /nfs-mount/post= gres/db or something like=C2=A0that ?=C2=A0
> and assign this value to the PGDATA ?=C2=A0
>
> If that is the case, then when and who should be creating the director= y DB ?=C2=A0
>
> Please correct me if I am wrong about the understanding.

You understood me perfectly well.

The data directory can either be created by "initdb", in which ca= se
the mount point must allow the PostgreSQL user to create a directory.
You could set the group of the mount point to the group of the
PostgreSQL user and use permissions 1770, which should be perfectly safe.
Alternatively, the root user could create the data directory with the
correct ownership and permissions prior to running "initdb".

Yours,
Laurenz Albe


--
-regards
Amol
--00000000000003c7ee0639e34668--