You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
statfs(2) lets callers probe for the existence of files, and retrieve information about the file system. We might want to restrict that.
There is already an existing LSM hook for that.
Having that access right should probably also enable the use of some related IOCTLs which are closely related, like FIGETBSZ and maybe FIBMAP and FS_IOC_FIEMAP.
The text was updated successfully, but these errors were encountered:
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. 🤔
About the ability to probe for file existence, the right approach would be #9 .
What are the legitimate use cases to use statfs(2)?
It looks like it is a tool for compatibility and performance to better interact with the running system.
What is the threat with 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 .
How to identify filesystems?
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
.The text was updated successfully, but these errors were encountered: