[RFC PATCH 3/5] samples/landlock: Add support for LANDLOCK_ACCESS_FS_CONNECT_UNIX

[Mickaël Salaün]

On Fri, Jan 02, 2026 at 10:53:49AM +0100, Günther Noack wrote:
> On Thu, Jan 01, 2026 at 05:39:26PM -0500, Demi Marie Obenour wrote:
> > On 1/1/26 17:38, Justin Suess wrote:
> > > On 1/1/26 17:19, Tingmao Wang wrote:
> > >> On 1/1/26 22:11, Demi Marie Obenour wrote:
> > >>> On 1/1/26 17:07, Tingmao Wang wrote:
> > >>>
> > >>> (snip)
> > >>>
> > >>>> Looking at this I guess it might also make sense for the kernel side to
> > >>>> enforce only being able to add LANDLOCK_ACCESS_FS_CONNECT_UNIX on socket
> > >>>> files (S_ISSOCK(d_backing_inode)) too in landlock_append_fs_rule?
> > >>>>
> > >>>> Also, for the sandboxer logic, maybe a better way would be having
> > >>>> LANDLOCK_ACCESS_FS_CONNECT_UNIX in ACCESS_FILE (matching the kernel code),
> > >>>> then another if(!S_ISSOCK) below this that will clear out
> > >>>> LANDLOCK_ACCESS_FS_CONNECT_UNIX if not socket.
> > >>> A process might legitimately need to connect to a socket that doesn't
> > >>> exist at the time it sandboxes itself.  Therefore, I think it makes
> > >>> sense to for LANDLOCK_ACCESS_FS_CONNECT_UNIX access to a directory
> > >>> to allow LANDLOCK_ACCESS_FS_CONNECT_UNIX to any socket under that
> > >>> directory.  This matches the flexibility mount namespaces can achieve.
> > >> Right, I forgot about the fact that we also need it on dirs, apologies.
> > >>
> > >> (But maybe it might still make sense to not allow this on files which are
> > >> neither a socket or a dir? (If the file later gets removed and recreated
> > >> as a socket, the rule would not apply retroactively anyway due to being
> > >> tied to the inode.))
> > > How do we handle IOCTL access on regular files? I think that landlock will let you put IOCTL rights on regular files even they are not valid for that operation.
> > 
> > Regular files definitely support ioctls.
> 
> The LANDLOCK_ACCESS_FS_IOCTL_DEV right only applies to ioctl(2)
> invocations on device files.
> 
> 
> > > Sockets seem like a similar case where the operation is only valid for a subset of file types.
> > > 
> > > I think we should mirror the existing behavior is for consistency.
> > > 
> > > Besides, restricting which file types can have that right also makes it harder for applications that may not care about the specific file type, but now would have to check the filetype before making a policy on them (also opening them to TOCTOU).
> > 
> > I agree.
> 
> I also agree with your interpretation, Justin.
> 
> For the record, Landlock's kernel implementation currently groups FS
> access rights into two groups:
> 
>  - file access rights
>  - directory-only rights
> 
> When adding a rule, the directory access rights can only be granted on
> a directory inode.  The file access rights can be granted on both a
> directory inode and a regular file inode.
> 
> It is pointless to grant the CONNECT_UNIX (or IOCTL_DEV) right on a
> file which is not a Unix socket (or device file).  But it complicates
> the userspace API if we introduce more special rules there. - Users of
> Landlock would have to keep track of all these special cases and
> mirror the logic, which is error prone.  IMHO is is granular enough if
> we differentiate between files and directories as we currently do.

Agreed. We discussed about making it more granular (see the IOCTL patch
series), but it is not worth it.  Even the directory/file
differentiation is questionable, but I initially made this decision to
incentivise user space to know if they are dealing with directories or
files because access right inheritance should be carefully managed.
In most cases, when programs sandbox themselves, they should not need to
stat the file because they should already know if it's a file or a
directory; only sandboxers need too check the file type.

> 
> For reference, this is documented at
> https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags
> and the logic is implemented in landlock_append_fs_rule() in fs.c.
> 
> (Actually, in the implementation, the IOCTL_DEV right is treated the
> same as one of the ACCESS_FILE rights - I should probably revise that
> documentation: That right does not *directly* apply to a directory
> inode, as directories are not device files.  It only inherits down in
> the file system hierarchy.  Looking back at earlier versions of the
> IOCTL_DEV patch set, it was different there.  I think I missed to keep
> the documentation in-line.)

Indeed