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

[Günther Noack]

On Fri, Jan 02, 2026 at 05:27:40AM -0500, Demi Marie Obenour wrote:
> On 1/2/26 05:16, Günther Noack wrote:
> > 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.
> 
> What about instead using the inode-based hooks for directory searching?
> SELinux can already restrict that.

Oh, thanks, good pointer!  I was under the impression that this didn't
exist yet -- I assume you are referring to the
security_inode_follow_link() hook, which is already happening during
path resolution?

I take it back then. :) If there is prior art, implementing this might
be more feasible than I thought.

–Günther