On Thursday, September 8, 2022 5:22:15 PM EDT Paul Moore wrote:
On Thu, Sep 8, 2022 at 5:14 PM Steve Grubb <sgrubb(a)redhat.com>
wrote:
> On Wednesday, September 7, 2022 4:23:49 PM EDT Paul Moore wrote:
> > On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb <sgrubb(a)redhat.com> wrote:
> > > On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs
wrote:
> > > > > > Ultimately I guess I'll leave it
upto audit subsystem what it
> > > > > > wants
> > > > > > to
> > > > > > have in its struct fanotify_response_info_audit_rule
because
> > > > > > for
> > > > > > fanotify subsystem, it is just an opaque blob it is
passing.
> > > > >
> > > > > In that case, let's stick with leveraging the type/len
fields in
> > > > > the
> > > > > fanotify_response_info_header struct, that should give us all
the
> > > > > flexibility we need.
> > > > >
> > > > > Richard and Steve, it sounds like Steve is already aware of
> > > > > additional
> > > > > information that he wants to send via the
> > > > > fanotify_response_info_audit_rule struct, please include that
in
> > > > > the
> > > > > next revision of this patchset. I don't want to get this
merged
> > > > > and
> > > > > then soon after have to hack in additional info.
> > > >
> > > > Steve, please define the type and name of this additional field.
> > >
> > > Maybe extra_data, app_data, or extra_info. Something generic that can
> > > be
> > > reused by any application. Default to 0 if not present.
> >
> > I think the point is being missed ... The idea is to not speculate on
> > additional fields, as discussed we have ways to handle that, the issue
> > was that Steve implied that he already had ideas for "things" he
> > wanted to add. If there are "things" that need to be added,
let's do
> > that now, however if there is just speculation that maybe someday we
> > might need to add something else we can leave that until later.
>
> This is not speculation. I know what I want to put there. I know you want
> to pin it down to exactly what it is. However, when this started a
> couple years back, one of the concerns was that we're building something
> specific to 1 user of fanotify. And that it would be better for all
> future users to have a generic facility that everyone could use if they
> wanted to. That's why I'm suggesting something generic, its so this is
> not special purpose that doesn't fit any other use case.
Well, we are talking specifically about fanotify in this thread and
dealing with data structures that are specific to fanotify. I can
understand wanting to future proof things, but based on what we've
seen in this thread I think we are all set in this regard.
I'm trying to abide by what was suggested by the fs-devel folks. I can live
with it. But if you want to make something non-generic for all users of
fanotify, call the new field "trusted". This would decern when a decision was
made because the file was untrusted or access denied for another reason.
You mention that you know what you want to put in the struct, why
not
share the details with all of us so we are all on the same page and
can have a proper discussion.
Because I want to abide by the original agreement and not impose opinionated
requirements that serve no one else. I'd rather have something anyone can
use. I want to play nice.
-Steve