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 1ubKN4-00Grl6-FG for pgsql-general@arkaria.postgresql.org; Mon, 14 Jul 2025 14:41: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 1ubKN2-008t2u-Fp for pgsql-general@arkaria.postgresql.org; Mon, 14 Jul 2025 14:41:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ubKN2-008t2m-3T for pgsql-general@lists.postgresql.org; Mon, 14 Jul 2025 14:41:32 +0000 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ubKN1-007Fei-0J for pgsql-general@lists.postgresql.org; Mon, 14 Jul 2025 14:41:31 +0000 Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3a4fd1ba177so2893312f8f.0 for ; Mon, 14 Jul 2025 07:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec.at; s=google; t=1752504088; x=1753108888; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=0ep0cRmgngoFgu9qCjbzxhNw4epXIZ1H4k4T+Dk64ug=; b=Vcy3P4iEwQ0vJtMIHgcWSNNVeMiiCMgeP63cGu8hduxDlFUVOzcIIP1jDJsr1K55u5 /HHdW3MR8LIe0BELNCL+DNFMDLklQvJceC0teP5lWjCq7xDr7LTce79bxOJ+Umj2T8cY 1NhLVy7sNLJX2RAJ3PHlobNFu+jeIInsnVQq3KFO/ef78nz01VtSxNnVvwuDf3ZGNEBD hWWPZ/i+EF8dp/8FIyrJulte50Irxv3E9gvUtMbt9tFHM1ZWGTAaR8DMJU6e9WQ4L+g8 nyFUkhOi08h5Yi5GjsH+RV73FjQ+QZPdncnTsYYyHGy/N3bXQwoHjeSxu3nbW8V/OzCq tm2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752504088; x=1753108888; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=0ep0cRmgngoFgu9qCjbzxhNw4epXIZ1H4k4T+Dk64ug=; b=i4sFjz001xbl2GuPcFQKVWzm4rMcO8sm28BrS0EOWIsalwRkr3X9/U3II/eJpJMkyu JcKCW1/KO8xe6YCWacPW4boaiJeJHbVLyJZoK3Yd5D968f5Wf3eJ787RYr+JgC6MVjy5 N/fbMiJttix6wceCRbUZo0TUFgS2W4y/3oOxUGhpg4T22BHI8LgH76TcsSOGtBfnpfVD E9Lt+PItGUGRVNcQ0PkcIQWUhTsnIPts2uYWFl0oZ2sIbZV+HcVLmFRp2ryGXOvWquFi Wv6CpYlQioPuel88ZY84WX7fPsjXLpNUma4Xd9j1nfmpBC2hs/hErdYnS+9Z0Cgu4a5N o+sQ== X-Gm-Message-State: AOJu0YyGEOK6ehlEBWRwgQGg7eghZebDFbZ0YBlG81r2KZSrTANUnS/a KWbt1no7s7/HuBP+L5U7HMQOTTWngwBybJNlF0dUjkfyBcpqPpDjp0bTbC/RxzVvrDA= X-Gm-Gg: ASbGncuqBZR7+u+Sl8nEa1HwSBe/S2x8wjkZygryT9DM3p+dakOjDIqCbVrU7DpdWnK f2TCZQFN9mqqrPYX8yCyOND0423PUcErVAfzEzILb8mXwB4acOJFR9EFStDDJuq3O+t31tMYEUk c60uHeaCe5X2ruVSuna1JHqFnZOhSV8eEQiBVfupb6dFhj6lRkAZ11RrmGuUu9cEXWAc12+muSI N6ckTAv5Cp59vTRUqa7P+7zCRq4OUX6GL7bAwMk65UfoEnXMqb+39ITNamzrKOczMDADS/BNo30 yhJM9lI89j6gqB+VnXsPF1g7dbFqihaU27Ei40vVRkQNaBqs/cJe/Jtjr/hhTC8OIfx1FRRSFUY 1uc8BaOMDwaDBLWnCxri+DIjZTtZEpXIjf/YAp0ZYKZF98oiSuQE= X-Google-Smtp-Source: AGHT+IHECvF9NJupr4ijPkbaM+0SIbvMBHt+7SNooeKdGJgpUZBA/zxye/QYXAd8POgULd4NVq9qug== X-Received: by 2002:a05:6000:2d0e:b0:3a5:2915:ed68 with SMTP id ffacd0b85a97d-3b5f1eae830mr7739021f8f.28.1752504087789; Mon, 14 Jul 2025 07:41:27 -0700 (PDT) Received: from laurenz.albe-K4N0CV00F97414D ([2001:871:5e:870b:3a5c:2fbf:b86f:9443]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b6039bdea0sm3722228f8f.65.2025.07.14.07.41.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Jul 2025 07:41:27 -0700 (PDT) Message-ID: Subject: Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS) From: Laurenz Albe To: Amol Inamdar Cc: pgsql-general@lists.postgresql.org Date: Mon, 14 Jul 2025 16:41:26 +0200 In-Reply-To: References: <13e3100fc7c7d14919c37943dcfd76b263cecce2.camel@cybertec.at> <0b3fb11184bf9ce6516ed1aa08af5dddc924f21c.camel@cybertec.at> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-1.fc42) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, 2025-07-14 at 18:32 +0530, Amol Inamdar wrote: > > 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 saf= e. >=20 > This exactly is the problem we are facing, to give you a summary,=C2=A0 > our NFS server is enabled with AT-TLS authentication > and we are accessing the server via a proxy server (Haproxy).=C2=A0 > This acts as our NFS client and it is configured with the=C2=A0 > required client certificates. >=20 > The outcome of above configuration is that any directory created=C2=A0 > in the NFS mount is always owned by the user in the certificates=C2=A0 > and if that user isn't present in the proxy container it is marked=C2=A0 > as nobody:nogroup, we tried various things like > created the user similar to postgres user so that the users ids match but= =C2=A0 > always ended up giving error=C2=A0=C2=A0=E2=80=9Cdata directory =E2=80=9C= /var/lib=E2=80=9D has wrong ownership=C2=A0 >=20 > Hence, we thought of skipping this check (Directory owner and postgres us= er validation) and=C2=A0 > wanted to understand the implication of the same. No; don't. Simply mount the directory once, create a subdirectory with the appropriate ownership and permissions, and there you go. Problem solved. Yours, Laurenz Albe