From: Steve Grubb <sgrubb@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: Jan Kara <jack@suse.cz>, Amir Goldstein <amir73il@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux-Audit Mailing List <linux-audit@redhat.com>,
linux-fsdevel@vger.kernel.org, Eric Paris <eparis@parisplace.org>
Subject: Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response
Date: Fri, 09 Sep 2022 00:03:53 -0400 [thread overview]
Message-ID: <2254543.ElGaqSPkdT@x2> (raw)
In-Reply-To: <Yxqn6NVQr0jTQHiu@madcap2.tricolour.ca>
On Thursday, September 8, 2022 10:41:44 PM EDT Richard Guy Briggs wrote:
> > 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.
>
> So, "u32 trusted;" ? How would you like that formatted?
> "fan_trust={0|1}"
So how does this play out if there is another user? Do they want a num= and
trust= if not, then the AUDIT_FANOTIFY record will have multiple formats
which is not good. I'd rather suggest something generic that can be
interpreted based on who's attached to fanotify. IOW we have a fan_type=0 and
then followed by info0= info1= the interpretation of those solely depend on
fan_type. If the fan_type does not need both, then any interpretation skips
what it doesn't need. If fan_type=1, then it follows what arg0= and arg1= is
for that format. But make this pivot on fan_type and not actual names.
> > > 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.
>
> If someone else wants to use something, why not give them a type of
> their own other than FAN_RESPONSE_INFO_AUDIT_RULE that they can shape
> however they like?
Please, let's keep AUDIT_FANOTIFY normalized but pivot on fan_type.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
WARNING: multiple messages have this Message-ID (diff)
From: Steve Grubb <sgrubb@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: Paul Moore <paul@paul-moore.com>, Jan Kara <jack@suse.cz>,
Linux-Audit Mailing List <linux-audit@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, Eric Paris <eparis@parisplace.org>,
Amir Goldstein <amir73il@gmail.com>
Subject: Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
Date: Fri, 09 Sep 2022 00:03:53 -0400 [thread overview]
Message-ID: <2254543.ElGaqSPkdT@x2> (raw)
In-Reply-To: <Yxqn6NVQr0jTQHiu@madcap2.tricolour.ca>
On Thursday, September 8, 2022 10:41:44 PM EDT Richard Guy Briggs wrote:
> > 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.
>
> So, "u32 trusted;" ? How would you like that formatted?
> "fan_trust={0|1}"
So how does this play out if there is another user? Do they want a num= and
trust= if not, then the AUDIT_FANOTIFY record will have multiple formats
which is not good. I'd rather suggest something generic that can be
interpreted based on who's attached to fanotify. IOW we have a fan_type=0 and
then followed by info0= info1= the interpretation of those solely depend on
fan_type. If the fan_type does not need both, then any interpretation skips
what it doesn't need. If fan_type=1, then it follows what arg0= and arg1= is
for that format. But make this pivot on fan_type and not actual names.
> > > 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.
>
> If someone else wants to use something, why not give them a type of
> their own other than FAN_RESPONSE_INFO_AUDIT_RULE that they can shape
> however they like?
Please, let's keep AUDIT_FANOTIFY normalized but pivot on fan_type.
-Steve
next prev parent reply other threads:[~2022-09-09 4:04 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-09 17:22 [PATCH v4 0/4] fanotify: Allow user space to pass back additional audit info Richard Guy Briggs
2022-08-09 17:22 ` Richard Guy Briggs
2022-08-09 17:22 ` [PATCH v4 1/4] fanotify: Ensure consistent variable type for response Richard Guy Briggs
2022-08-09 17:22 ` Richard Guy Briggs
2022-08-09 17:22 ` [PATCH v4 2/4] fanotify: define struct members to hold response decision context Richard Guy Briggs
2022-08-09 17:22 ` Richard Guy Briggs
2022-08-10 6:22 ` Amir Goldstein
2022-08-10 6:22 ` Amir Goldstein
2022-08-19 11:24 ` Jan Kara
2022-08-19 11:24 ` Jan Kara
2022-08-10 14:28 ` kernel test robot
2022-08-10 14:28 ` kernel test robot
2022-08-19 16:25 ` Richard Guy Briggs
2022-08-19 16:25 ` Richard Guy Briggs
2022-08-19 16:25 ` Richard Guy Briggs
2022-08-19 17:17 ` Nick Desaulniers
2022-08-19 17:17 ` Nick Desaulniers
2022-08-19 17:17 ` Nick Desaulniers
2022-08-19 21:45 ` Richard Guy Briggs
2022-08-19 21:45 ` Richard Guy Briggs
2022-08-19 21:45 ` Richard Guy Briggs
2022-08-12 0:23 ` Matthew Bobrowski
2022-08-12 0:23 ` Matthew Bobrowski
2022-08-19 11:16 ` Jan Kara
2022-08-19 11:16 ` Jan Kara
2022-08-19 11:13 ` Jan Kara
2022-08-19 11:13 ` Jan Kara
2022-08-09 17:22 ` [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response Richard Guy Briggs
2022-08-09 17:22 ` [PATCH v4 3/4] fanotify,audit: " Richard Guy Briggs
2022-08-10 20:32 ` kernel test robot
2022-08-10 20:32 ` kernel test robot
2022-08-16 0:22 ` Paul Moore
2022-08-16 0:22 ` Paul Moore
2022-08-31 21:07 ` Richard Guy Briggs
2022-08-31 21:07 ` Richard Guy Briggs
2022-08-31 21:25 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
2022-08-31 21:25 ` [PATCH v4 3/4] fanotify,audit: " Steve Grubb
2022-08-31 22:19 ` Richard Guy Briggs
2022-08-31 22:19 ` Richard Guy Briggs
2022-08-31 23:55 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
2022-08-31 23:55 ` [PATCH v4 3/4] fanotify,audit: " Steve Grubb
2022-09-01 1:47 ` Paul Moore
2022-09-01 1:47 ` Paul Moore
2022-09-01 7:51 ` Jan Kara
2022-09-01 7:51 ` Jan Kara
2022-09-01 18:31 ` Paul Moore
2022-09-01 18:31 ` Paul Moore
2022-09-07 18:43 ` Richard Guy Briggs
2022-09-07 18:43 ` Richard Guy Briggs
2022-09-07 20:11 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
2022-09-07 20:11 ` [PATCH v4 3/4] fanotify,audit: " Steve Grubb
2022-09-07 20:23 ` Paul Moore
2022-09-07 20:23 ` Paul Moore
2022-09-08 21:14 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
2022-09-08 21:14 ` [PATCH v4 3/4] fanotify,audit: " Steve Grubb
2022-09-08 21:22 ` Paul Moore
2022-09-08 21:22 ` Paul Moore
2022-09-09 2:20 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
2022-09-09 2:20 ` [PATCH v4 3/4] fanotify,audit: " Steve Grubb
2022-09-09 2:41 ` Richard Guy Briggs
2022-09-09 2:41 ` Richard Guy Briggs
2022-09-09 3:25 ` Paul Moore
2022-09-09 3:25 ` Paul Moore
2022-09-09 4:03 ` Steve Grubb [this message]
2022-09-09 4:03 ` Steve Grubb
2022-09-09 11:09 ` Jan Kara
2022-09-09 11:09 ` Jan Kara
2022-09-09 14:22 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
2022-09-09 14:22 ` [PATCH v4 3/4] fanotify,audit: " Steve Grubb
2022-09-09 14:38 ` Richard Guy Briggs
2022-09-09 14:38 ` Richard Guy Briggs
2022-09-09 14:55 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
2022-09-09 14:55 ` [PATCH v4 3/4] fanotify,audit: " Steve Grubb
2022-09-09 18:50 ` Richard Guy Briggs
2022-09-09 18:50 ` Richard Guy Briggs
2022-08-09 17:22 ` [PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string Richard Guy Briggs
2022-08-09 17:22 ` [PATCH v4 4/4] fanotify,audit: " Richard Guy Briggs
2022-08-10 19:15 ` [PATCH v4 4/4] fanotify, audit: " Steve Grubb
2022-08-10 19:15 ` [PATCH v4 4/4] fanotify,audit: " Steve Grubb
2022-08-11 2:23 ` [PATCH v4 4/4] fanotify, audit: " Richard Guy Briggs
2022-08-11 2:23 ` [PATCH v4 4/4] fanotify,audit: " Richard Guy Briggs
2022-08-15 21:15 ` [PATCH v4 4/4] fanotify, audit: " Steve Grubb
2022-08-15 21:15 ` [PATCH v4 4/4] fanotify,audit: " Steve Grubb
2022-08-16 0:31 ` [PATCH v4 4/4] fanotify, audit: " Paul Moore
2022-08-16 0:31 ` [PATCH v4 4/4] fanotify,audit: " Paul Moore
2022-08-16 13:37 ` [PATCH v4 4/4] fanotify, audit: " Steve Grubb
2022-08-16 13:37 ` [PATCH v4 4/4] fanotify,audit: " Steve Grubb
2022-08-19 21:42 ` [PATCH v4 4/4] fanotify, audit: " Richard Guy Briggs
2022-08-19 21:42 ` [PATCH v4 4/4] fanotify,audit: " Richard Guy Briggs
2022-08-10 5:21 ` [PATCH v4 0/4] fanotify: Allow user space to pass back additional audit info Amir Goldstein
2022-08-10 5:21 ` Amir Goldstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2254543.ElGaqSPkdT@x2 \
--to=sgrubb@redhat.com \
--cc=amir73il@gmail.com \
--cc=eparis@parisplace.org \
--cc=jack@suse.cz \
--cc=linux-audit@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rgb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.