Open gnoack opened 5 months ago
This is related to #11, but I'm wondering if it would be a good idea to tie statfs(2)
to LANDLOCK_ACCESS_FS_READ_METADATA
. :thinking:
About the ability to probe for file existence, the right approach would be #9 .
statfs(2)
?It looks like it is a tool for compatibility and performance to better interact with the running system.
statfs(2)
?statfs(2)
enables to get metadata about filesystems, not direct data. It is a way to create cover channels, like so many other ways though. Do we really need to restrict its use?
The answer to this question could impact #4 .
If we need to control this interface, should we use a landlock_path_beneath_attr
or a new rule type to scope to a mount point or a block device instead of a file hierarchy? This new rule could contain almost the same fields but with a different semantic (e.g. not parent_fd
but mount_fd
or dev_fd
instead).
statfs(2) lets callers probe for the existence of files, and retrieve information about the file system. We might want to restrict that.
FIGETBSZ
and maybeFIBMAP
andFS_IOC_FIEMAP
.