Re: thoughts about fanotify and HSM

From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Dave Chinner <david@fromorbit.com>
Subject: Re: thoughts about fanotify and HSM
Date: Wed, 12 Oct 2022 17:44:02 +0200	[thread overview]
Message-ID: <20221012154402.h5al3junehejsv24@quack3> (raw)
In-Reply-To: <CAOQ4uxjAn50Z03SysRT0v8AVmtvDHpFUMG6_TYCCX_L9zBD+fg@mail.gmail.com>

Hi Amir!

On Fri 07-10-22 16:58:21, Amir Goldstein wrote:
> > > The other use case of automatic inode marks I was thinking about,
> > > which are even more relevant for $SUBJECT is this:
> > > When instantiating a dentry with an inode that has xattr
> > > "security.fanotify.mask" (a.k.a. persistent inode mark), an inode
> > > mark could be auto created and attached to a group with a special sb
> > > mark (we can limit a single special mark per sb).
> > > This could be implemented similar to get_acl(), where i_fsnotify_mask
> > > is always initialized with a special value (i.e. FS_UNINITIALIZED)
> > > which is set to either 0 or non-zero if "security.fanotify.mask" exists.
> > >
> > > The details of how such an API would look like are very unclear to me,
> > > so I will try to focus on the recursive auto inode mark idea.
> >
> > Yeah, although initializing fanotify marks based on xattrs does not look
> > completely crazy I can see a lot of open questions there so I think
> > automatic inode mark idea has more chances for success at this point :).
> 
> I realized that there is one sort of "persistent mark" who raises
> less questions - one that only has an ignore mask.
> 
> ignore masks can have a "static" namespace that is not bound to any
> specific group, but rather a set of groups that join this namespace.
> 
> I played with this idea and wrote some patches:
> https://github.com/amir73il/linux/commits/fan_xattr_ignore_mask

I have glanced over the patches. In general the idea looks OK to me but I
have some concerns:

1) Technically, it may be challenging to call into filesystem xattr
handling code on first event generated by the inode - that may generate
some unexpected lock recursion for some filesystems and some events which
trigger the initialization...

2) What if you set the xattr while the group is already listening to
events? Currently the change will get ignored, won't it? But I guess this
could be handled by clearing the "cached" flag when the xattr is set.

3) What if multiple applications want to use the persistent mark
functionality? I think we need some way to associate a particular
fanotify group with a particular subset of fanotify xattrs so that
coexistence of multiple applications is possible...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR