[PATCH v2 0/6] Landlock: Implement scope control for pathname Unix sockets

[Günther Noack]

On Sun, Feb 08, 2026 at 02:57:10AM +0000, Tingmao Wang wrote:
> On 2/5/26 10:27, Mickaël Salaün wrote:
> > On Thu, Feb 05, 2026 at 09:02:19AM +0100, Günther Noack wrote:
> >> [...]
> >>
> >> The implementation of this approach would be that we would have to
> >> join the functionality from the scoped and FS-based patch set, but
> >> without introducing the LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET flag in
> >> the UAPI.
> >
> > Right, this looks good to me.  We'll need to sync both patch series and
> > remove the scope flag from UAPI.  I'll let you and Tingmao work together
> > for the next series.  The "IPC scoping" documentation section should
> > mention LANDLOCK_ACCESS_FS_RESOLVE_UNIX even if it's not a scope flag.
> 
> This sounds good to me.  I'm not sure how much code we can reuse out of
> the existing LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET patchset - but I think
> the selftest patches could still largely be useful (after changing e.g.
> create_scoped_domain() to use the RESOLVE_UNIX fs access instead of the
> scope bit for pathname sockets).  The fs-based rules (i.e. "exceptions")
> can then be tested separately from the scope tests (and would also check
> for things like path being different across mount namespaces etc).
> 
> Günther, feel free to take anything out of the existing scope series, if
> you feel it would be useful.  Also let me know if you would like me to
> help with any part of the RESOLVE_UNIX series if you feel that would be
> useful (but you don't have to if not).

Thank you, Tingmao!

So far, the selftests that I already had in fs_test.c were
straightforward to extend so that they cover the new cases.  I had a
look at your patch set, but found the scoping tests difficult to port
to fs_test.c, but I'll double check that we don't miss anything.
Either way, I'll make sure that you'll get appropriate credit for
it. :)

–Günther

(P.S. If this mail looks familiar, it's because I accidentally replied
with an earlier version of that to the wrong mail earlier today
(https://lore.kernel.org/all/20260208.b25c4105bc03@gnoack.org/) –
Replying here again so that this answer makes more sense.)