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

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:

quoted

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@huawei.com/ (local)
[2] https://lore.kernel.org/all/abc960a1-e66e-792e-6869-cfd201c29dbe@digikod.net/ (local)

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