[PATCH] landlock: Clarify documentation for the IOCTL access right

Mickaël Salaün mic at digikod.net
Mon Jan 12 16:07:50 UTC 2026


On Sun, Jan 11, 2026 at 06:52:04PM +0100, Günther Noack wrote:
> Move the description of the LANDLOCK_ACCESS_FS_IOCTL_DEV access right
> together with the file access rights.
> 
> This group of access rights applies to files (in this case device
> files), and they can be added to file or directory inodes using
> landlock_add_rule(2).  The check for that works the same for all file
> access rights, including LANDLOCK_ACCESS_FS_IOCTL_DEV.
> 
> Invoking ioctl(2) on directory FDs can not currently be restricted
> with Landlock.  Having it grouped separately in the documentation is a
> remnant from earlier revisions of the LANDLOCK_ACCESS_FS_IOCTL_DEV
> patch set.
> 
> Link: https://lore.kernel.org/all/20260108.Thaex5ruach2@digikod.net/
> Signed-off-by: Günther Noack <gnoack3000 at gmail.com>

Thanks, applied.

> ---
>  include/uapi/linux/landlock.h | 37 ++++++++++++++++-------------------
>  1 file changed, 17 insertions(+), 20 deletions(-)
> 
> diff --git a/include/uapi/linux/landlock.h b/include/uapi/linux/landlock.h
> index eac65da687c1..fbd18cf60a88 100644
> --- a/include/uapi/linux/landlock.h
> +++ b/include/uapi/linux/landlock.h
> @@ -216,6 +216,23 @@ struct landlock_net_port_attr {
>   *   :manpage:`ftruncate(2)`, :manpage:`creat(2)`, or :manpage:`open(2)` with
>   *   ``O_TRUNC``.  This access right is available since the third version of the
>   *   Landlock ABI.
> + * - %LANDLOCK_ACCESS_FS_IOCTL_DEV: Invoke :manpage:`ioctl(2)` commands on an opened
> + *   character or block device.
> + *
> + *   This access right applies to all `ioctl(2)` commands implemented by device
> + *   drivers.  However, the following common IOCTL commands continue to be
> + *   invokable independent of the %LANDLOCK_ACCESS_FS_IOCTL_DEV right:
> + *
> + *   * IOCTL commands targeting file descriptors (``FIOCLEX``, ``FIONCLEX``),
> + *   * IOCTL commands targeting file descriptions (``FIONBIO``, ``FIOASYNC``),
> + *   * IOCTL commands targeting file systems (``FIFREEZE``, ``FITHAW``,
> + *     ``FIGETBSZ``, ``FS_IOC_GETFSUUID``, ``FS_IOC_GETFSSYSFSPATH``)
> + *   * Some IOCTL commands which do not make sense when used with devices, but
> + *     whose implementations are safe and return the right error codes
> + *     (``FS_IOC_FIEMAP``, ``FICLONE``, ``FICLONERANGE``, ``FIDEDUPERANGE``)
> + *
> + *   This access right is available since the fifth version of the Landlock
> + *   ABI.
>   *
>   * Whether an opened file can be truncated with :manpage:`ftruncate(2)` or used
>   * with `ioctl(2)` is determined during :manpage:`open(2)`, in the same way as
> @@ -275,26 +292,6 @@ struct landlock_net_port_attr {
>   *   If multiple requirements are not met, the ``EACCES`` error code takes
>   *   precedence over ``EXDEV``.
>   *
> - * The following access right applies both to files and directories:
> - *
> - * - %LANDLOCK_ACCESS_FS_IOCTL_DEV: Invoke :manpage:`ioctl(2)` commands on an opened
> - *   character or block device.
> - *
> - *   This access right applies to all `ioctl(2)` commands implemented by device
> - *   drivers.  However, the following common IOCTL commands continue to be
> - *   invokable independent of the %LANDLOCK_ACCESS_FS_IOCTL_DEV right:
> - *
> - *   * IOCTL commands targeting file descriptors (``FIOCLEX``, ``FIONCLEX``),
> - *   * IOCTL commands targeting file descriptions (``FIONBIO``, ``FIOASYNC``),
> - *   * IOCTL commands targeting file systems (``FIFREEZE``, ``FITHAW``,
> - *     ``FIGETBSZ``, ``FS_IOC_GETFSUUID``, ``FS_IOC_GETFSSYSFSPATH``)
> - *   * Some IOCTL commands which do not make sense when used with devices, but
> - *     whose implementations are safe and return the right error codes
> - *     (``FS_IOC_FIEMAP``, ``FICLONE``, ``FICLONERANGE``, ``FIDEDUPERANGE``)
> - *
> - *   This access right is available since the fifth version of the Landlock
> - *   ABI.
> - *
>   * .. warning::
>   *
>   *   It is currently not possible to restrict some file-related actions
> -- 
> 2.52.0
> 
> 



More information about the Linux-security-module-archive mailing list