[RFC PATCH 0/5] landlock: Pathname-based UNIX connect() control

[Mickaël Salaün]

On Fri, Jan 02, 2026 at 11:25:38AM +0100, Günther Noack wrote:
> On Fri, Jan 02, 2026 at 11:16:33AM +0100, Günther Noack wrote:
> > Regarding the un-restrictable operations, Tingmao's pointers are
> > correct.  In the warning box in the documentation, the missing
> > operations that I am aware of are (a) the Unix socket connect()
> > operation, and (b) the symlink lookup which happens implicitly during
> > path traversal and which Landlock and other LSMs can not control
> > through LSM hooks at the moment.  (A symlink always gets implicitly
> > resolved during path lookup even when you do not have directory read
> > permissions on the directory where the symlink is.)
> 
> I forgot to mention - the error codes returned by Landlock make it
> possible to probe for the presence of files, even when all available

It is not specifically the error codes but the inability to restrict
path resolution.

> FS access rights are denied on a directory.  Attempting to open a file
> for reading will return EEXIST if it is missing, but will return
> EACCES if it is denied by Landlock.
> 
> gnoack:/tmp/xxx$ ls
> foobar.txt
> gnoack:/tmp/xxx$ landlock-restrict -rofiles /proc /usr /bin /etc/ -- /bin/cat foobar.txt
> cat: foobar.txt: Permission denied
> gnoack:/tmp/xxx$ landlock-restrict -rofiles /proc /usr /bin /etc/ -- /bin/cat nonexistent.txt
> cat: nonexistent.txt: No such file or directory
> gnoack:/tmp/xxx$ landlock-restrict -rofiles /proc /usr /bin /etc/ -- /bin/ls
> ls: cannot open directory '.': Permission denied

FYI, there are several ways to infer file presence, and this also work
with other LSMs such as AppArmor and Tomoyo.  It is a limitation of
path-based hooks, see https://github.com/landlock-lsm/linux/issues/52

As Tingmao noted, this is part of Landlock's documentation, but it could
be improved.