Re: [PATCH RFC -next 00/12] landlock: Add READ_METADATA and WRITE_METADATA access rights

[Cai Xinchen]

Thank you for review!

I will link the feature request
(https://github.com/landlock-lsm/linux/issues/11) in the v2 cover letter.

For https://github.com/landlock-lsm/linux/issues/18, the current
READ_METADATA cannot solve this problem, and I don't have a good idea 
for now.

For path_* rename, I'd rather keep the inode_* names:

* There is precedent for the mismatch: the inode_getattr hook
  upstream already takes a "const struct path *" (this series just
  aligns the other metadata hooks with it).

* The path_* prefix has an established meaning in the LSM hook
  interface: it denotes the pathname-based (TOMOYO/AppArmor-style)
  hooks that are invoked at the VFS path level *before* the
  corresponding inode_* hook, as a paired, duplicate check
  serving a different class of LSMs.  For example, a chmod(2)
  currently runs security_path_chmod() (fs/open.c, for TOMOYO and
  AppArmor) and then, via notify_change(),
  security_inode_setattr() (for SELinux, Smack and now Landlock);
  vfs_mknod() similarly calls both security_path_mknod() and
  security_inode_mknod().  Renaming inode_setattr to
  path_setattr would put two path_-prefixed hooks with different
  call contracts into the same syscall, and path_chown(path,
  uid, gid) next to a path_setattr(path, attr) would read as a
  redundant pair, even though they belong to different hook
  families.  Landlock itself already uses the path_* family for
  its real path-level hooks (e.g. path_truncate for the TRUNCATE
  right), so mixing renamed inode hooks into that prefix would
  also blur its own hook table.

* If the consensus is that these hooks should be renamed, I think
  that should be a standalone, tree-wide rename series (including
  inode_getattr), so that BPF programs only break once instead of
  twice.

On 9/26/2026 4:27 PM, Günther Noack wrote:
> On Thu, Sep 24, 2026 at 06:48:19PM +0800, Cai Xinchen wrote:
> > This series adds two new Landlock filesystem access rights,
> > LANDLOCK_ACCESS_FS_READ_METADATA and LANDLOCK_ACCESS_FS_WRITE_METADATA,
> > which control access to file and directory metadata such as inode
> > attributes (mode, ownership, timestamps), extended attributes and POSIX
> > ACLs.  It picks up the work from the "landlock: add chmod and chown
> > support" series [1] and follows the coarse-grained grouping discussed in
> > that thread [2]: instead of separate chmod/chown rights, metadata
> > operations are grouped into one read and one write right.
> >
> > Landlock evaluates access rights on a per-path basis, but the metadata
> > related LSM hooks (inode_getattr, inode_setattr, inode_setxattr,
> > inode_getxattr, inode_listxattr, inode_removexattr, inode_set_acl,
> > inode_get_acl, inode_remove_acl) only receive the dentry of the accessed
> > object.  Patches 1-7 therefore first pass struct path instead of dentry
> > through the metadata-related VFS helpers and LSM hooks.  This is a pure
> > refactoring with no behavior change, split so that every patch builds
> > and works on its own:
> >
> >    1: notify_change() and its callers
> >    2: inode_setsecctx hook (must come before 3: the SELinux and Smack
> >       implementations call __vfs_setxattr_locked internally)
> >    3: xattr helpers, which also drops a redundant EVM xattr size sanity
> >       check whose vfs_getxattr() call only has a dentry and therefore
> >       cannot be migrated to the new path-based signature
> >    4: POSIX ACL helpers
> >    5: inode_setattr hook
> >    6: inode xattr hooks
> >    7: inode POSIX ACL hooks
> >
> > Two deliberate scoping decisions for this refactor:
> >
> > - The hooks consistently take struct path rather than struct file.  The
> >    VFS call sites involved (chmod(2), chown(2), utimensat(2), xattr(2)
> >    and ACL syscalls) operate on paths, and several of them (lstat(2),
> >    lchown(2), llistxattr(2), ...) have no struct file to begin with.
> >
> > - struct inode_operations->setattr still receives (idmap, dentry, attr).
> >    Only the VFS boundary (notify_change()) and the LSM hook layer see the
> >    path, which keeps the refactor contained to fs/attr.c and the LSM
> >    infrastructure instead of touching every filesystem.
> >
> > Patches 8-12 then implement the new rights, their tests, the sandboxer
> > sample and the documentation.  Semantics:
> >
> > - READ_METADATA covers stat(2) and friends, getxattr(2) and friends,
> >    listxattr(2) and friends, and POSIX ACL reads.
> > - WRITE_METADATA covers chmod(2), chown(2), utimensat(2), setxattr(2),
> >    removexattr(2) and friends, and POSIX ACL set and remove.
> > - Only explicit metadata changes requested by user space are restricted.
> >    Implicit changes performed by the kernel (e.g. timestamp updates on
> >    write(2), size changes on truncate(2)) are not, and neither are
> >    chmod(2)/chown(2) calls that change nothing (e.g. chown(2) with
> >    (-1, -1), which never reaches the hook), matching the SELinux
> >    inode_setattr behavior.
> > - Kernel-internal accesses performed with override_creds() (e.g.
> >    overlayfs, cachefiles) and kernel threads without a Landlock domain
> >    (e.g. nfsd, ksmbd) are not restricted.
> >
> > The Landlock ABI version is incremented from 11 to 12.
> >
> > The series is based on linux-next commit 5c4d4169604b ("Add linux-next
> > specific files for 20260921").
> >
> > Testing: each patch has been built for aarch64 (gcc, -Werror) and the
> > landlock selftests (445 tests, including the new ones) pass in QEMU on
> > aarch64; base_test reports ABI v12.
> >
> > [1] https://lore.kernel.org/all/20220827111215.131442-1-xiujianfeng@xxxxxxxxxx/
> > [2] https://lore.kernel.org/all/abc960a1-e66e-792e-6869-cfd201c29dbe@xxxxxxxxxxx/
> Thank you for sending this patch set!
>
> Some meta-remarks at the beginning:
>
> * You might want to link the bugtracker feature request:
>    https://github.com/landlock-lsm/linux/issues/11
> * In the final version, I think it's preferred to merge patches 8
>    (adding the access right enums) and 9 (adding the LSM hooks that use
>    them).  Having the feature as an atomic commit makes it harder to
>    accidentally mess it up during a backport, because you can't patch 8
>    without 9.
> * As Paul alluded to, the changes to the LSM hook interface and to the
>    existing callers in VFS are likely the hardest part of this patch
>    set.  Alexei from the BPF subsystem has also reiterated recently
>    that he wants BPF to be looped into such changes.  BPF hooks do not
>    give the same backwards compatibility guarantees as the syscall
>    layer, but there are existing users of LSM hooks specifically
>    through the BPF LSM.
>
> * In https://github.com/landlock-lsm/linux/issues/18, we came across
>    statfs(), which returns file system meta-information based for the
>    file system that a given file belongs to.  I have weak confidence
>    that READ_METADATA would be the right access right to protect this
>    with, but it's a somewhat related operation.  Maybe you have some
>    thoughts on this?
>
> More concrete questions:
>
> * If a "inode" LSM hook gets a "path" argument now, should it be
>    renamed from "inode_..." to "path_..."?
>
>    (Maybe the BPF people can chime in about to what extent that would
>    cause additional churn for BPF users, in a situation where they
>    anyway already need to make a change due to the changing function
>    signature?)
>
> –Günther