Re: [PATCH v1 0/2] two suggested iouring op audit updates
On Sat, Jan 28, 2023 at 11:48 AM Steve Grubb wrote: > On Friday, January 27, 2023 5:53:24 PM EST Paul Moore wrote: > > On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe wrote: > > > On 1/27/23 3:38 PM, Paul Moore wrote: > > > > On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe wrote: > > > >> On 1/27/23 12:42 PM, Paul Moore wrote: > > > >>> On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe wrote: > > > On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > > > > A couple of updates to the iouring ops audit bypass selections > > > > suggested in consultation with Steve Grubb. > > > > > > > > Richard Guy Briggs (2): > > > > io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > > > > io_uring,audit: do not log IORING_OP_*GETXATTR > > > > > > > > io_uring/opdef.c | 4 +++- > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > Look fine to me - we should probably add stable to both of them, > > > just to keep things consistent across releases. I can queue them up > > > for 6.3. > > > >>> > > > >>> Please hold off until I've had a chance to look them over ... > > > >> > > > >> I haven't taken anything yet, for things like this I always let it > > > >> simmer until people have had a chance to do so. > > > > > > > > Thanks. FWIW, that sounds very reasonable to me, but I've seen lots > > > > of different behaviors across subsystems and wanted to make sure we > > > > were on the same page. > > > > > > Sounds fair. BTW, can we stop CC'ing closed lists on patch > > > submissions? Getting these: > > > > > > Your message to Linux-audit awaits moderator approval > > > > > > on every reply is really annoying. > > > > We kinda need audit related stuff on the linux-audit list, that's our > > mailing list for audit stuff. > > > > However, I agree that it is crap that the linux-audit list is > > moderated, but unfortunately that isn't something I control (I haven't > > worked for RH in years, and even then the list owner was really weird > > about managing the list). Occasionally I grumble about moving the > > kernel audit development to a linux-audit list on vger but haven't > > bothered yet, perhaps this is as good a reason as any. > > > > Richard, Steve - any chance of opening the linux-audit list? > > Unfortunately, it really has to be this way. I deleted 10 spam emails > yesterday. It seems like some people subscribed to this list are compromised. > Because everytime there is a legit email, it's followed in a few seconds by a > spam email. > > Anyways, all legit email will be approved without needing to be subscribed. The problem is that other subsystem developers who aren't subscribed to the linux-audit list end up getting held mail notices (see the comments from Jens). The moderation of linux-audit, as permissive as it may be for proper emails, is a problem for upstream linux audit development, I would say much more so than 10/day mails. If you are unable/unwilling to switch linux-audit over to an open mailing list we should revisit moving over to a vger list; at least for upstream kernel development, you are welcome to stick with the existing redhat.com list for discussion of your userspace tools. -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v1 0/2] two suggested iouring op audit updates
On Friday, January 27, 2023 5:53:24 PM EST Paul Moore wrote: > On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe wrote: > > On 1/27/23 3:38 PM, Paul Moore wrote: > > > On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe wrote: > > >> On 1/27/23 12:42 PM, Paul Moore wrote: > > >>> On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe wrote: > > On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > > > A couple of updates to the iouring ops audit bypass selections > > > suggested in consultation with Steve Grubb. > > > > > > Richard Guy Briggs (2): > > > io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > > > io_uring,audit: do not log IORING_OP_*GETXATTR > > > > > > io_uring/opdef.c | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > Look fine to me - we should probably add stable to both of them, > > just to keep things consistent across releases. I can queue them up > > for 6.3. > > >>> > > >>> Please hold off until I've had a chance to look them over ... > > >> > > >> I haven't taken anything yet, for things like this I always let it > > >> simmer until people have had a chance to do so. > > > > > > Thanks. FWIW, that sounds very reasonable to me, but I've seen lots > > > of different behaviors across subsystems and wanted to make sure we > > > were on the same page. > > > > Sounds fair. BTW, can we stop CC'ing closed lists on patch > > submissions? Getting these: > > > > Your message to Linux-audit awaits moderator approval > > > > on every reply is really annoying. > > We kinda need audit related stuff on the linux-audit list, that's our > mailing list for audit stuff. > > However, I agree that it is crap that the linux-audit list is > moderated, but unfortunately that isn't something I control (I haven't > worked for RH in years, and even then the list owner was really weird > about managing the list). Occasionally I grumble about moving the > kernel audit development to a linux-audit list on vger but haven't > bothered yet, perhaps this is as good a reason as any. > > Richard, Steve - any chance of opening the linux-audit list? Unfortunately, it really has to be this way. I deleted 10 spam emails yesterday. It seems like some people subscribed to this list are compromised. Because everytime there is a legit email, it's followed in a few seconds by a spam email. Anyways, all legit email will be approved without needing to be subscribed. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v1 0/2] two suggested iouring op audit updates
On 1/27/23 3:53 PM, Paul Moore wrote: > On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe wrote: >> On 1/27/23 3:38 PM, Paul Moore wrote: >>> On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe wrote: On 1/27/23 12:42 PM, Paul Moore wrote: > On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe wrote: >> On 1/27/23 10:23 AM, Richard Guy Briggs wrote: >>> A couple of updates to the iouring ops audit bypass selections >>> suggested in >>> consultation with Steve Grubb. >>> >>> Richard Guy Briggs (2): >>> io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE >>> io_uring,audit: do not log IORING_OP_*GETXATTR >>> >>> io_uring/opdef.c | 4 +++- >>> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> Look fine to me - we should probably add stable to both of them, just >> to keep things consistent across releases. I can queue them up for 6.3. > > Please hold off until I've had a chance to look them over ... I haven't taken anything yet, for things like this I always let it simmer until people have had a chance to do so. >>> >>> Thanks. FWIW, that sounds very reasonable to me, but I've seen lots >>> of different behaviors across subsystems and wanted to make sure we >>> were on the same page. >> >> Sounds fair. BTW, can we stop CC'ing closed lists on patch >> submissions? Getting these: >> >> Your message to Linux-audit awaits moderator approval >> >> on every reply is really annoying. > > We kinda need audit related stuff on the linux-audit list, that's our > mailing list for audit stuff. Sure, but then it should be open. Or do separate postings or something. CC'ing a closed list with open lists and sending email to people that are not on that closed list is bad form. -- Jens Axboe -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v1 0/2] two suggested iouring op audit updates
On 1/27/23 3:38 PM, Paul Moore wrote: > On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe wrote: >> On 1/27/23 12:42 PM, Paul Moore wrote: >>> On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe wrote: On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > A couple of updates to the iouring ops audit bypass selections suggested > in > consultation with Steve Grubb. > > Richard Guy Briggs (2): > io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > io_uring,audit: do not log IORING_OP_*GETXATTR > > io_uring/opdef.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Look fine to me - we should probably add stable to both of them, just to keep things consistent across releases. I can queue them up for 6.3. >>> >>> Please hold off until I've had a chance to look them over ... >> >> I haven't taken anything yet, for things like this I always let it >> simmer until people have had a chance to do so. > > Thanks. FWIW, that sounds very reasonable to me, but I've seen lots > of different behaviors across subsystems and wanted to make sure we > were on the same page. Sounds fair. BTW, can we stop CC'ing closed lists on patch submissions? Getting these: Your message to Linux-audit awaits moderator approval on every reply is really annoying. -- Jens Axboe -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v1 0/2] two suggested iouring op audit updates
On Fri, Jan 27, 2023 at 6:02 PM Jens Axboe wrote: > On 1/27/23 3:53 PM, Paul Moore wrote: > > On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe wrote: > >> On 1/27/23 3:38 PM, Paul Moore wrote: > >>> On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe wrote: > On 1/27/23 12:42 PM, Paul Moore wrote: > > On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe wrote: > >> On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > >>> A couple of updates to the iouring ops audit bypass selections > >>> suggested in > >>> consultation with Steve Grubb. > >>> > >>> Richard Guy Briggs (2): > >>> io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > >>> io_uring,audit: do not log IORING_OP_*GETXATTR > >>> > >>> io_uring/opdef.c | 4 +++- > >>> 1 file changed, 3 insertions(+), 1 deletion(-) > >> > >> Look fine to me - we should probably add stable to both of them, just > >> to keep things consistent across releases. I can queue them up for 6.3. > > > > Please hold off until I've had a chance to look them over ... > > I haven't taken anything yet, for things like this I always let it > simmer until people have had a chance to do so. > >>> > >>> Thanks. FWIW, that sounds very reasonable to me, but I've seen lots > >>> of different behaviors across subsystems and wanted to make sure we > >>> were on the same page. > >> > >> Sounds fair. BTW, can we stop CC'ing closed lists on patch > >> submissions? Getting these: > >> > >> Your message to Linux-audit awaits moderator approval > >> > >> on every reply is really annoying. > > > > We kinda need audit related stuff on the linux-audit list, that's our > > mailing list for audit stuff. > > Sure, but then it should be open. Or do separate postings or something. > CC'ing a closed list with open lists and sending email to people that > are not on that closed list is bad form. Agree, that's why I said in my reply that it was crap that the linux-audit list is moderated and asked Richard/Steve to open it up. -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v1 0/2] two suggested iouring op audit updates
On 2023-01-27 16:02, Jens Axboe wrote: > On 1/27/23 3:53 PM, Paul Moore wrote: > > On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe wrote: > >> On 1/27/23 3:38 PM, Paul Moore wrote: > >>> On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe wrote: > On 1/27/23 12:42 PM, Paul Moore wrote: > > On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe wrote: > >> On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > >>> A couple of updates to the iouring ops audit bypass selections > >>> suggested in > >>> consultation with Steve Grubb. > >>> > >>> Richard Guy Briggs (2): > >>> io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > >>> io_uring,audit: do not log IORING_OP_*GETXATTR > >>> > >>> io_uring/opdef.c | 4 +++- > >>> 1 file changed, 3 insertions(+), 1 deletion(-) > >> > >> Look fine to me - we should probably add stable to both of them, just > >> to keep things consistent across releases. I can queue them up for 6.3. > > > > Please hold off until I've had a chance to look them over ... > > I haven't taken anything yet, for things like this I always let it > simmer until people have had a chance to do so. > >>> > >>> Thanks. FWIW, that sounds very reasonable to me, but I've seen lots > >>> of different behaviors across subsystems and wanted to make sure we > >>> were on the same page. > >> > >> Sounds fair. BTW, can we stop CC'ing closed lists on patch > >> submissions? Getting these: > >> > >> Your message to Linux-audit awaits moderator approval > >> > >> on every reply is really annoying. > > > > We kinda need audit related stuff on the linux-audit list, that's our > > mailing list for audit stuff. > > Sure, but then it should be open. Or do separate postings or something. > CC'ing a closed list with open lists and sending email to people that > are not on that closed list is bad form. I've made an inquiry. > Jens Axboe - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v1 0/2] two suggested iouring op audit updates
On Fri, Jan 27, 2023 at 5:46 PM Jens Axboe wrote: > On 1/27/23 3:38 PM, Paul Moore wrote: > > On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe wrote: > >> On 1/27/23 12:42 PM, Paul Moore wrote: > >>> On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe wrote: > On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > > A couple of updates to the iouring ops audit bypass selections > > suggested in > > consultation with Steve Grubb. > > > > Richard Guy Briggs (2): > > io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > > io_uring,audit: do not log IORING_OP_*GETXATTR > > > > io_uring/opdef.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > Look fine to me - we should probably add stable to both of them, just > to keep things consistent across releases. I can queue them up for 6.3. > >>> > >>> Please hold off until I've had a chance to look them over ... > >> > >> I haven't taken anything yet, for things like this I always let it > >> simmer until people have had a chance to do so. > > > > Thanks. FWIW, that sounds very reasonable to me, but I've seen lots > > of different behaviors across subsystems and wanted to make sure we > > were on the same page. > > Sounds fair. BTW, can we stop CC'ing closed lists on patch > submissions? Getting these: > > Your message to Linux-audit awaits moderator approval > > on every reply is really annoying. We kinda need audit related stuff on the linux-audit list, that's our mailing list for audit stuff. However, I agree that it is crap that the linux-audit list is moderated, but unfortunately that isn't something I control (I haven't worked for RH in years, and even then the list owner was really weird about managing the list). Occasionally I grumble about moving the kernel audit development to a linux-audit list on vger but haven't bothered yet, perhaps this is as good a reason as any. Richard, Steve - any chance of opening the linux-audit list? -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v1 0/2] two suggested iouring op audit updates
On Fri, Jan 27, 2023 at 2:43 PM Jens Axboe wrote: > On 1/27/23 12:42 PM, Paul Moore wrote: > > On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe wrote: > >> On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > >>> A couple of updates to the iouring ops audit bypass selections suggested > >>> in > >>> consultation with Steve Grubb. > >>> > >>> Richard Guy Briggs (2): > >>> io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > >>> io_uring,audit: do not log IORING_OP_*GETXATTR > >>> > >>> io_uring/opdef.c | 4 +++- > >>> 1 file changed, 3 insertions(+), 1 deletion(-) > >> > >> Look fine to me - we should probably add stable to both of them, just > >> to keep things consistent across releases. I can queue them up for 6.3. > > > > Please hold off until I've had a chance to look them over ... > > I haven't taken anything yet, for things like this I always let it > simmer until people have had a chance to do so. Thanks. FWIW, that sounds very reasonable to me, but I've seen lots of different behaviors across subsystems and wanted to make sure we were on the same page. -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v1 0/2] two suggested iouring op audit updates
On 1/27/23 12:42 PM, Paul Moore wrote: > On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe wrote: >> On 1/27/23 10:23 AM, Richard Guy Briggs wrote: >>> A couple of updates to the iouring ops audit bypass selections suggested in >>> consultation with Steve Grubb. >>> >>> Richard Guy Briggs (2): >>> io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE >>> io_uring,audit: do not log IORING_OP_*GETXATTR >>> >>> io_uring/opdef.c | 4 +++- >>> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> Look fine to me - we should probably add stable to both of them, just >> to keep things consistent across releases. I can queue them up for 6.3. > > Please hold off until I've had a chance to look them over ... I haven't taken anything yet, for things like this I always let it simmer until people have had a chance to do so. -- Jens Axboe -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v1 0/2] two suggested iouring op audit updates
On Fri, Jan 27, 2023 at 12:40 PM Jens Axboe wrote: > On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > > A couple of updates to the iouring ops audit bypass selections suggested in > > consultation with Steve Grubb. > > > > Richard Guy Briggs (2): > > io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > > io_uring,audit: do not log IORING_OP_*GETXATTR > > > > io_uring/opdef.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > Look fine to me - we should probably add stable to both of them, just > to keep things consistent across releases. I can queue them up for 6.3. Please hold off until I've had a chance to look them over ... -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v1 0/2] two suggested iouring op audit updates
On 1/27/23 10:23 AM, Richard Guy Briggs wrote: > A couple of updates to the iouring ops audit bypass selections suggested in > consultation with Steve Grubb. > > Richard Guy Briggs (2): > io_uring,audit: audit IORING_OP_FADVISE but not IORING_OP_MADVISE > io_uring,audit: do not log IORING_OP_*GETXATTR > > io_uring/opdef.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Look fine to me - we should probably add stable to both of them, just to keep things consistent across releases. I can queue them up for 6.3. -- Jens Axboe -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
