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: > > On Tue, Feb 02, 2021 at 05:27:05PM +0100, Mickaël Salaün wrote: > >> From: Mickaël Salaün <mic@xxxxxxxxxxxxxxxxxxx> > >> > >> 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. > >> 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 > >
