On 6/11/23 21:33, Amir Goldstein wrote:
On Mon, Nov 6, 2023 at 2:11 PM Karel Zak <kzak@xxxxxxxxxx> wrote:
On Wed, Nov 01, 2023 at 07:52:45PM +0800, Ian Kent wrote:
On 25/10/23 22:01, Miklos Szeredi wrote:
Looks ok to me,covers the primary cases I needed when I worked
on using fsinfo() in systemd.
Our work on systemd was about two areas: get mount info (stat/listmount()
now) from the kernel, and get the mount ID from notification.
There was watch_queue.h with WATCH_TYPE_MOUNT_NOTIFY and struct
mount_notification->auxiliary_mount (aka mount ID) and event subtype
to get the change status (new mount, umount, etc.)
For example David's:
https://patchwork.kernel.org/project/linux-security-module/patch/155991711016.15579.4449417925184028666.stgit@xxxxxxxxxxxxxxxxxxxxxx/
Do we have any replacement for this?
The plan is to extend fanotify for mount namespace change notifications.
Here is a simple POC for FAN_UNMOUNT notification:
https://lore.kernel.org/linux-fsdevel/20230414182903.1852019-1-amir73il@xxxxxxxxx/
I was waiting for Miklos' patches to land, so that we can report
mnt_id_unique (of mount and its parent mount) in the events.
The plan is to start with setting a mark on a vfsmount to get
FAN_MOUNT/FAN_UNMOUNT notifications for changes to direct
children of that mount.
I'll have a look at what I needed when I was working to implement
this in systemd. Without looking at the code I can say I was
handling mount, umount and I think remount events so that's probably
a minimum.
As I mentioned earlier I found I also need event rate management
which was a new requirement at the time.
This part, I was planning to do myself. I cannot say for sure when
I will be able to get to it, but it should be a rather simple patch.
If anybody else would like to volunteer for the task, I will be
happy to assist.
I would like to help with this but I'm not familiar with fanotify
so I'll need to spend a bit of time on that. I am just about in
a position to do that now.
I'll also be looking at the watch queue framework that did get merged
back then, I'm not sure how that will turn out.
Not sure if we are going to need special notifications for mount
move and mount beneath?
Yes that will be an interesting question, I have noticed Christians'
work on mount beneath.
We need to provide the ability to monitor mount tables as is done by
using the proc mount lists to start with and I'm pretty sure that
includes at least mount, umount and moves perhaps more but I'll check
what I was using.
Not sure if we are going to need notifications on mount attribute
changes?
Also an interesting question, we will see in time I guess.
You would think that the mount/umount/move events would get what's
needed because (assuming mount move maps to remount) mount, umount
and remount should cover cases were mounted mount attributes change.
We may later also implement a mark on a mount namespace
to get events on all mount namespace changes.
Monitoring the proc mount tables essentially provides lists of mounts
that are present in a mount namespace (as seen by the given process)
so this is going to be needed sooner rather than later if we hope to
realize improvements from our new system calls.
Ian
