Thank for this patch series! I'll send more reviews tomorrow, but in the meantime here are some answers:
On Mon, Sep 28, 2026 at 02:52:02PM +0800, Cai Xinchen wrote: > 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. I had the same though as Günther on this, but I'll leave that up to Paul. Regarding the BPF LSM use case, I don't think it would make a big difference. Anyway, some BPF selftests need to be updated at the same time, which will also make the changes clear to the BPF folks. > > * 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. As a general rule, please create bisectable patches (e.g. any patch must pass BPF and Landlock selftests; all dependent kernel code must build). But new tests still deserve their own patches. > > 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/[email protected]/ > > > [2] > > > https://lore.kernel.org/all/[email protected]/ > > 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 >
