[PATCH v4 2/6] landlock: Control pathname UNIX domain socket resolution by path

[Günther Noack]

On Mon, Feb 09, 2026 at 06:28:24PM +0100, Mickaël Salaün wrote:
> On Mon, Feb 09, 2026 at 11:21:57AM +0100, Günther Noack wrote:
> > On Mon, Feb 09, 2026 at 12:10:12AM +0100, Günther Noack wrote:
> > > +static int hook_unix_find(const struct path *const path, struct sock *other,
> > > +			  int flags)
> > > +{
> > > +	const struct landlock_ruleset *dom_other;
> > > +	const struct landlock_cred_security *subject;
> > > +	struct layer_access_masks layer_masks;
> > > +	struct landlock_request request = {};
> > > +	static const struct access_masks fs_resolve_unix = {
> > > +		.fs = LANDLOCK_ACCESS_FS_RESOLVE_UNIX,
> > > +	};
> > > +	int type = other->sk_type;
> > > +
> > > +	/* Lookup for the purpose of saving coredumps is OK. */
> > > +	if (flags & SOCK_COREDUMP)
> > > +		return 0;
> > > +
> > > +	/* Only stream, dgram and seqpacket sockets are restricted. */
> > > +	if (type != SOCK_STREAM && type != SOCK_DGRAM && type != SOCK_SEQPACKET)
> > > +		return 0;
> >
> > [...]
>
> You can remove these type checks.  We're building Landlock access
> control wrt to the (moving) current state of Linux, and the goal is to
> cover most/useful access types that currently make sense.  Once access
> type is implemented, it should handle (by default) future features
> related to the kernel object to make sure a sandbox is well covered.
> This LANDLOCK_ACCESS_FS_RESOLVE_UNIX right is really about UNIX sockets
> that can be resolved through the filesystem, so this should handle
> current and potential future UNIX sockets as well.
> 
> If a new named UNIX socket type is created, Landlock should handle that
> with this access right, unless there is a specific semantic (e.g.
> coredump), in which case we'll update the access right, and potentially
> add a new one if it makes sense.
> 
> I was thinking about calling WARN_ON_ONCE() but this is not worth it.

Sounds good, removed the check for the next version.

The possibility of a new UNIX socket type seems anyway pretty
theoretical, and even if an additional type were added, it's not
entirely unthinkable that we would actually want to have it covered
under the same access right.

–Günther