Re: [PATCH 2/2] landlock: Clarify IPC scoping documentation

["Günther Noack" <gnoack@google.com>]

Hello Alejandro!

On Sun, Feb 02, 2025 at 01:51:54PM +0100, Alejandro Colomar wrote:
> On Fri, Jan 24, 2025 at 04:59:29PM +0100, G??nther Noack wrote:
> > On Fri, Jan 24, 2025 at 03:44:45PM +0000, G??nther Noack wrote:
> > > -IPC scoping does not support exceptions, so if a domain is scoped, no rules can
> > > -be added to allow access to resources or processes outside of the scope.
> > > +interactions between sandboxes.  Therefore, at ruleset creation time, each
> > > +Landlock domain can restrict the scope for certain operations, so that these
> > > +operations can only reach out to processes within the same Landlock domain or in
> > > +a nested Landlock domain (the "scope").
> > > +
> > > +The operations which can be scoped are:
> > > +
> > > +``LANDLOCK_SCOPE_SIGNAL``
> > > +    When set,
> 
> Do we need to say when set?  I'd say that's redundant (of course if you
> don't set a flag, its effects don't apply).

Removed, thanks!


> > > this limits the sending of signals to target processes which run
> > > +    within the same or a nested Landlock domain.
> > > +
> > > +``LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET``
> > > +    When set, this limits the set of abstract :manpage:`unix(7)` sockets we can
> > > +    :manpage:`connect(2)` to to socket addresses which were created by a process
> > > +    in the same or a nested Landlock domain.
> > > +
> > > +    A :manpage:`send(2)` on a non-connected datagram socket is treated like an
> > > +    implicit :manpage:`connect(2)` and will be blocked when the remote end does
> 
> I think *if* would be more appropriate than *when* here.
> 
> > > +    not stem from the same or a nested Landlock domain.
> 
> This could be read such that send(2) is replaced by connect(2) on a
> non-connected datagram socket.  But you want to say that a connect(2)
> is implicitly executed before the actual send(2) (which is still
> executed, if connect(2) succeeds).

Thanks, that can indeed be misunderstood.

> How about this wording?
> 
> 	If send(2) is used on a non-connected datagram socket, an
> 	implicit connect(2) is executed first, and will be blocked when
> 	the remote end does not ....

I think this would be misleading as well, because the send(2) on the
non-connected datagram socket does *not* actually perform an implicit
connect(2).  (If it were doing that, the socket would be connected afterwards,
but it isn't.)  But we *do* initiate a communication with a previously unknown
remote address, just like connect(2), so we enforce the same Landlock policy as
for connect(2).

(Remark, connected datagram sockets sound absurd, because there is no connection
at the network layer. On datagram sockets, connect(2) only fixes the destination
address so that it can be omitted in subsequent send(2) calls.).

Rewording it to:

  A sendto(2) on a non-connected datagram socket is treated as if
  it were doing an implicit connect(2) and will be blocked if the
  remote end does not stem from the same or a nested Landlock domain.

(P.S. I also replaced send(2) with sendto(2), which is a bit more appropriate in
the middle paragraph - you can not actually pass the destination address with
send(2), that only works with sendto(2).  I replaced it in the third paragraph
as well for consistency. It still makes sense IMHO considering that send(2) is a
special case of sendto(2).)

—Günther