VMS has had the ability, right since the beginning, to reference files
and directories by their filesystem-unique IDs. So there is this
long-standing assumption that access to a file is guarded by the file protection itself, not by that on any path to it.

In POSIX systems, on the other hand, the original approximate
equivalent to a file ID (the inode number) was never usable to
reference the file directly: you always had to use the filename, and
the names of any containing directories, to construct a path to get to
it to open it, get info about it or whatever. So the security model
has always assumed that you can limit access to a file independently
of its own protection settings, by limiting access to its containing directory(ies).

Linux now has the ability to reference a file by its “handle” <https://manpages.debian.org/2/open_by_handle_at.2.en.html>. This is a persistent unique ID that survives moves/renames of the item within
the same filesystem, though not of course deletion or moving to a
different filesystem. The format of this ID information is up to the
filesystem implementation, and may not be supported by some filesystem
types.

Note that, while construction of a file handle is not privileged,
using one to access a file is.

Note also the “CAP_xxx” business. What Linux calls “capabilities” is basically a close copy of the VMS privilege mask mechanism.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)