Re: Bypassing Directory Ownership Check in PostgreSQL 16.6 with Secure z/OS NFS (AT-TLS)

On 2025-07-14 10:07:20 -0400, Tom Lane wrote:
> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> > It is not a good idea to have a mount point be the data directory.
>
> ^^^ This. ^^^
>
> That is primarily for safety reasons: if for some reason the
> filesystem gets dismounted, or hasn't come on-line yet during
> a reboot, you do not want Postgres to be able to write on the
> underlying mount-point directory. There is a sobering tale
> in this old thread:
>
> https://www.postgresql.org/message-id/flat/41BFAB7C.5040108%40joeconway.com
>
> Now it didn't help any that they were using a start script that
> would automatically run initdb if it didn't see a data directory
> where expected. But even without that, you are in for a world of
> hurt if the mount drops while the server is running and the server
> has any ability to write on the underlying storage; it will think
> whatever it was able to write is safely down on disk. To prevent
> that, the server must not have write permissions on the mount
> point, which dictates making a separate data directory (with
> different ownership/permissions) just below the mount.

Be careful: There are two different directorys involved in a mount
point. The one in the parent filesystem and the one in the mounted file
system.

E.g.:

# mkdir /mnt/demo
# stat /mnt/demo
File: /mnt/demo
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 254,0 Inode: 317 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)

So here we have inode 317 on device 254,0 and unsurprisingly it belongs
to root and is only writable by root.

Now let's mount a filesystem:

# mount /dev/vgroot/demo /mnt/demo
# stat /mnt/demo
File: /mnt/demo
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 254,13 Inode: 2 Links: 3
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)

This is now inode 2 on device 254,13 (i.e. the root directory on
/dev/vgroot/demo). Since I just created that it also belongs to root.
Let's change that:

# chown postgres: /mnt/demo
# stat /mnt/demo
File: /mnt/demo
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 254,13 Inode: 2 Links: 3
Access: (0755/drwxr-xr-x) Uid: ( 108/postgres) Gid: ( 114/postgres)

Ok, now it belongs to postgres and postgres could create files,
subdirectories, etc.

But when I unmount it:

# umount /mnt/demo
# stat /mnt/demo
File: /mnt/demo
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 254,0 Inode: 317 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)

Lo and behold: The original Inode is back and unchanged.

The user postgres couldn't write to that directory if it tried to.

That said, there are of course some remaining failure modes:

1) An admin might notice the wrong permissions and "fix" them without
investigating the cause
2) Some automated procedure (running as root) might "fix" the
permissions at startup (like the initdb in the example) or during an
upgrade.
3) use your imagination ;-).

hjp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp(at)hjp(dot)at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"