Hello! On Fri, Sep 25, 2026 at 02:03:05PM -0400, Justin Suess 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: > > > I like these patches, but is the ability to read metadata already > sorta controlled by LANDLOCK_ACCESS_FS_READ_DIR on the parent > directory? > > The one case I see this being different is: > > 1. if you wanted to grant read access to the file, but not metadata > read access, but I can't think of any usecase for being able to read > the contents of a file, but not the metadata. (see below) > > 2. If you had the absolute path already and didn't need READ_DIR. > > I see introducing this READ_METADATA as causing potential > hard-to-diagnose issues. > > Say you handle READ_METADATA and READ_FILE, but only grant READ_FILE. > > The program can technically open the file with the READ_FILE permission, > but it may error out because the stat() on it beforehand failed. > It's pretty common for programs to do that kind of thing (stat before > open), like for checking for config files (strace bash and you see it > stat .profile, /etc/profile) > > There may be other bugs, because being able to set permissions to read > a file *but not read it's metadata* isn't possible currently in posix > acl and userspace may not work well if that assumption no longer holds. > > So maybe WRITE_METADATA is good enough?
The existing use cases are the combinations of (a) READ_DIR allowed/denied and (b) READ_METADATA allowed/denied. Because these two access rights overlap slightly, it seems likely that for a given directory or file, users will want to either grant both, or deny both. At the moment, where the (not yet existing) READ_METADATA is implicitly always allowed, the problematic case is the one where the Landlock user wants to deny READ_DIR, but where much of the same metadata is still available through stat() and the various get-attribute syscalls. (c.f. the warning box in the Landlock docs [1]) In my view the READ_METADATA right closes a gap that READ_DIR left open (which is also potentially surprising to callers if they did not read the docs closely). Also, if its implementation is symmetric to WRITE_METADATA, I feel that it's worth having it in the same patch set. –Günther P.S.: I know, even after we can control stat(), there are likely ways to infer the presence of a file by observing Landlock error codes. This would be nice to fix as well, but is harder to do without controlling the path walk itself [2]. But also, the fact that this is currently not controllable is not an excuse for leaving READ_METADATA open IMHO. [1] https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags [2] https://github.com/landlock-lsm/linux/issues/9
