[PATCH v4 0/6] querying mount attributes

[Ian Kent]

On 6/11/23 21:33, Amir Goldstein wrote:
> On Mon, Nov 6, 2023 at 2:11 PM Karel Zak <kzak at redhat.com> 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@warthog.procyon.org.uk/
>>
>> 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@gmail.com/
>
> 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