[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOQ4uxgn--PshKxMDmM4YoDQ8x3+a0NwCv+Bppjq-3w9V+Sxpg@mail.gmail.com>
Date: Mon, 6 Nov 2023 15:33:23 +0200
From: Amir Goldstein <amir73il@...il.com>
To: Karel Zak <kzak@...hat.com>
Cc: Ian Kent <raven@...maw.net>, Miklos Szeredi <mszeredi@...hat.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-api@...r.kernel.org, linux-man@...r.kernel.org,
linux-security-module@...r.kernel.org,
David Howells <dhowells@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>,
Christian Brauner <christian@...uner.io>,
Matthew House <mattlloydhouse@...il.com>,
Florian Weimer <fweimer@...hat.com>,
Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v4 0/6] querying mount attributes
On Mon, Nov 6, 2023 at 2:11 PM Karel Zak <kzak@...hat.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.
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.
Not sure if we are going to need special notifications for mount
move and mount beneath?
Not sure if we are going to need notifications on mount attribute
changes?
We may later also implement a mark on a mount namespace
to get events on all mount namespace changes.
If you have any feedback about this rough plan, or more items
to the wish list, please feel free to share them.
Thanks,
Amir.
Powered by blists - more mailing lists