Re: [PATCH v8 10/19] fanotify: introduce FAN_PRE_ACCESS permission event

[Amir Goldstein <amir73il@gmail.com>]

On Thu, Nov 21, 2024 at 11:44 AM Jan Kara <jack@suse.cz> wrote:
>
> On Fri 15-11-24 10:30:23, Josef Bacik wrote:
> > From: Amir Goldstein <amir73il@gmail.com>
> >
> > Similar to FAN_ACCESS_PERM permission event, but it is only allowed with
> > class FAN_CLASS_PRE_CONTENT and only allowed on regular files and dirs.
> >
> > Unlike FAN_ACCESS_PERM, it is safe to write to the file being accessed
> > in the context of the event handler.
> >
> > This pre-content event is meant to be used by hierarchical storage
> > managers that want to fill the content of files on first read access.
> >
> > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
>
> Here I was wondering about one thing:
>
> > +     /*
> > +      * Filesystems need to opt-into pre-content evnets (a.k.a HSM)
> > +      * and they are only supported on regular files and directories.
> > +      */
> > +     if (mask & FANOTIFY_PRE_CONTENT_EVENTS) {
> > +             if (!(path->mnt->mnt_sb->s_iflags & SB_I_ALLOW_HSM))
> > +                     return -EINVAL;
> > +             if (!is_dir && !d_is_reg(path->dentry))
> > +                     return -EINVAL;
> > +     }
>
> AFAICS, currently no pre-content events are generated for directories. So
> perhaps we should refuse directories here as well for now? I'd like to

readdir() does emit PRE_ACCESS (without a range) and also always
emitted ACCESS_PERM. my POC is using that PRE_ACCESS to populate
directories on-demand, although the functionality is incomplete without the
"populate on lookup" event.

> avoid the mistake of original fanotify which had some events available on
> directories but they did nothing and then you have to ponder hard whether
> you're going to break userspace if you actually start emitting them...

But in any case, the FAN_ONDIR built-in filter is applicable to PRE_ACCESS.

Thanks,
Amir.