Re: [PATCH v3 5/5] landlock: Document ioctl support

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

Hi!

On Fri, Aug 18, 2023 at 06:28:41PM +0200, Mickaël Salaün wrote:
> This looks good!
> 
> On Mon, Aug 14, 2023 at 07:28:16PM +0200, Günther Noack wrote:
> > +IOCTL support
> > +-------------
> > +
> > +The ``LANDLOCK_ACCESS_FS_IOCTL`` access right restricts the use of
> > +:manpage:`ioctl(2)`, but it only applies to newly opened files.  This means
> > +specifically that pre-existing file descriptors like STDIN, STDOUT and STDERR
> 
> According to man pages (and unlike IOCTL commands) we should not
> capitalize stdin, stdout and stderr.

Done.

> > +are unaffected.
> > +
> > +Users should be aware that TTY devices have traditionally permitted to control
> > +other processes on the same TTY through the ``TIOCSTI`` and ``TIOCLINUX`` IOCTL
> > +commands.  It is therefore recommended to close inherited TTY file descriptors.
> 
> Good to see such warnings in the documentation.
> 
> We could also propose a simple solution to still uses stdin, stdout and
> stderr without complex TTY proxying: re-opening the TTY, or replacing
> related FD thanks to /proc/self/fd/*
> 
> For instance, with shell scripts it would look like this:
> exec </proc/self/fd/0
> exec >/proc/self/fd/1
> exec 2>/proc/self/fd/2
> 
> Because of TIOCGWINSZ and TCGETS, an interactive shell may not work as
> expected though.

I inserted the phrase

  ..., or to reopen them from ``/proc/self/fd/*`` without the
  ``LANDLOCK_ACCESS_FS_IOCTL`` right, if possible.

to hint at that approach.

I added "if possible" there, because there are thorny edge cases that make it
difficult as a general approach -- the open(2) can fail if a stacked Landlock
policy exists.

—Günther

-- 
Sent using Mutt 🐕 Woof Woof