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

[Günther Noack]

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.

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

–Günther