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

["Günther Noack" <gnoack3000@gmail.com>]

On Thu, Jan 01, 2026 at 05:44:51PM -0500, Demi Marie Obenour wrote:
> On 1/1/26 17:34, Tingmao Wang wrote:
> > On 1/1/26 22:14, Demi Marie Obenour wrote:
> >> [...]
> >> Does this leave directory traversal as the only missing Landlock
> >> filesystem access control?  Ideally Landlock could provide the same
> >> isolation from the filesystem that mount namespaces do.
> > 
> > I think that level of isolation would require path walk control - see:
> > https://github.com/landlock-lsm/linux/issues/9
> > 
> > (Landlock also doesn't currently control some metadata operations - see
> > the warning at the end of the "Filesystem flags" section in [1])
> > 
> > [1]: https://docs.kernel.org/6.18/userspace-api/landlock.html#filesystem-flags
> 
> Could this replace all of the existing hooks?

If you do not need to distinguish between the different operations
which Landlock offers access rights for, but you only want to limit
the visibility of directory hierarchies in the file system, then yes,
the path walk control described in issue 9 would be sufficient and a
more complete control.

The path walk control is probably among the more difficult Landlock
feature requests.  A simple implementation would be easy to implement
technically, but it also requires a new LSM hook which will have to
get called *during* path lookup, and we'd have to make sure that the
performance impact stays in check.  Path lookup is after all a very
central facility in a OS kernel.

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.)

–Günther