On Wed, Feb 10, 2021 at 09:17:25PM +0100, Mickaël Salaün wrote:

On 10/02/2021 20:36, Serge E. Hallyn wrote:

quoted

On Tue, Feb 02, 2021 at 05:27:05PM +0100, Mickaël Salaün wrote:

quoted

From: Mickaël Salaün <redacted>

Thanks to the Landlock objects and ruleset, it is possible to identify
inodes according to a process's domain.  To enable an unprivileged

This throws me off a bit.  "identify inodes according to a process's domain".
What exactly does it mean?  "identify" how ?

A domain is a set of rules (i.e. layers of rulesets) enforced on a set
of threads. Inodes are tagged per domain (i.e. not system-wide) and
actions are restricted thanks to these tags, which form rules. It means
that the created access-controls are scoped to a set of threads.

Thanks, that's helpful.  To me it would be much clearer if you used the word
'tagged' :

  Using the Landlock objects and ruleset, it is possible to tag inodes
  according to a process's domain.

quoted

quoted

process to express a file hierarchy, it first needs to open a directory
(or a file) and pass this file descriptor to the kernel through
landlock_add_rule(2).  When checking if a file access request is
allowed, we walk from the requested dentry to the real root, following
the different mount layers.  The access to each "tagged" inodes are
collected according to their rule layer level, and ANDed to create
access to the requested file hierarchy.  This makes possible to identify
a lot of files without tagging every inodes nor modifying the
filesystem, while still following the view and understanding the user
has from the filesystem.

Add a new ARCH_EPHEMERAL_INODES for UML because it currently does not
keep the same struct inodes for the same inodes whereas these inodes are
in use.

-serge