Re: [PATCH v2 3/6] samples/landlock: Support LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET

["Mickaël Salaün" <mic@digikod.net>]

On Sat, Jan 31, 2026 at 05:48:24PM +0000, Tingmao Wang wrote:
> On 1/29/26 21:27, Mickaël Salaün wrote:
> > We should have a (potentially small) description of what this patch
> > does, even if it's a bit redundant with the subject.
> >
> >
> > On Tue, Dec 30, 2025 at 05:20:21PM +0000, Tingmao Wang wrote:
> >> Signed-off-by: Tingmao Wang <m@maowtm.org>
> >> ---
> >>
> >> I've decided to use "u" as the character to control this scope bit since
> >> it stands for (normal) Unix sockets.  Imo using "p" or "n" would make it less
> >> clear / memorable.  Open to suggestions.
> >
> > Looks good to me.
> >
> >>
> >> Also, open to suggestion whether socket scoping (pathname and abstract)
> >> should be enabled by default, if LL_SCOPED is not set.  This would break
> >> backward compatibility, but maybe we shouldn't guarentee backward
> >> compatibility of this sandboxer in the first place, and almost all cases
> >> of Landlock usage would want socket scoping.
> >
> > I agree that this example could have better defaults, but this should be
> > done with a standalone patch series.  An important point to keep in mind
> > is that this example is used by developers (e.g. potential copy/paste),
> > so we need to be careful to not encourage them to create code which is
> > backward incompatible.  I think the best way to do it is to request a
> > default behavior for a specific Landlock ABI version (e.g. with a new
> > parameter).
> 
> Just to make sure we're on the same page, I was only talking about whether
> we keep the behavior of the sandboxer "backward compatible" (i.e. if
> someone ran a program that relied on accessing UNIX sockets of more
> privileged programs, if we make the sandboxer start enforcing socket
> scoping by default, their program would stop working under this
> sandboxer), I was not suggesting that we do something which will cause the
> sandboxer itself to no longer work on older kernels.

Yep, I extrapolated a bit.

> 
> But on second thought, the sandboxer is already not designed to be relied
> upon to always behave the same way after an update, since the user don't
> get to choose which handled access rights are added to the ruleset.  With
> new bits added to either ACCESS_FS_ROUGHLY_READ or
> ACCESS_FS_ROUGHLY_WRITE, the policy effectively gets more restrictive
> automatically.  For example, once Günther's patch [1] that adds
> LANDLOCK_ACCESS_FS_RESOLVE_UNIX is merged, the sandboxer will effectively
> starts restricting pathname UNIX sockets "by default" anyway (under any
> dirs not listed in LL_FS_RW).  So maybe we don't need to think too hard
> about this.

Indeed :)

> 
> [1]: https://lore.kernel.org/all/20260119203457.97676-6-gnoack3000@gmail.com/
>