Thread (33 messages) 33 messages, 9 authors, 12d ago

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

flat view

From: Mickaël Salaün <mic@digikod.net>
Date: 2026-09-28 19:27:33
Also in: driver-core, linux-block, linux-cifs, linux-doc, linux-fsdevel, linux-integrity, linux-kselftest, linux-nfs, linux-unionfs, lkml, netfs, selinux

On Fri, Sep 25, 2026 at 01:07:08PM -0400, Paul Moore wrote:
On Fri, Sep 25, 2026 at 11:33 AM Christian Brauner [off-list ref] wrote:
quoted
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.
This is mostly fine for me. @Michael, for the fs side of things I would
give you a stable branch vfs-7.*.shared.landlock.path that you can pull
once this is ready.
This is in my queue, but I haven't reviewed the changes yet.

@Christian, I'm guessing you will merge patches 1/12, 3/13, and 4/12
since those are the VFS changes?  Once you have a branch for that, and
we have all the necessary ACKs, I'll merge the LSM changes in 2/12,
5/12, 6/12, and 7/12 and then Mickaël can merge the Landlock patches.

Are we all okay with that?
I guess the initial branch would be Christian's one, then Paul's would
start from this branch and add the LSM patches on top of it, and then
I'll do the same with the Landlock changes?  If Christian needs to
change his branch, Paul would have to rebase on top of the new branch,
and that would cascade to me.  That will be an interesting gymnastic,
especially if there are substantive changes in the VFS (which could lead
to headaches for the -next merges), but we can try.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help