On Monday, October 16, 2017 3:15:03 PM EDT Paul Moore wrote: > >> > The audit subsystem allows selecting audit events based on watches for > >> > a particular behavior like writing to a file. A lot of syscalls have > >> > been added without updating the list. This patch adds 2 syscalls to the > >> > write filters: fallocate and renameat2. > >> > > >> > Signed-off-by: sgrubb <sgrubb(a)redhat.com&gt; > >> > >> Reviewed-by: Richard Guy Briggs <rgb(a)redhat.com&gt; > > > > Please add a link to the issue number in the body of the patch > > description: > > > > See: https://github.com/linux-audit/audit-kernel/issues/67 > > FWIW, I don't really care if the upstream issue is included in the > submitted patch; if you want to include it - great, if you don't - > that's fine too. The commit description needs to stand on its own, > regardless of any external issue trackers, mailing lists, etc. I honestly don't know what the protocol is here. Should I resend the patch with that or is that fixed up in the merge process? The reason I ask is on the user space side I never make anyone resend a patch unless its grossly wrong or incomplete. I just fix it. But that's what I do and not everyone works that way.

On Thu, Oct 12, 2017 at 11:24 PM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > The audit subsystem allows selecting audit events based on watches for > a particular behavior like writing to a file. A lot of syscalls have > been added without updating the list. This patch adds 2 syscalls to the > write filters: fallocate and renameat2. > > Signed-off-by: sgrubb <sgrubb(a)redhat.com&gt; > --- > include/asm-generic/audit_dir_write.h | 4 ++++ > include/asm-generic/audit_write.h | 3 +++ > 2 files changed, 7 insertions(+) FWIW, I expect that this syscall list is almost always going to be out of date; it's just the way this feature is designed. That doesn't mean I'm not going to merge fixes, I just want to make sure expectations are set accordingly. Before I merge this Steve, can you explain why fallocate() should be on the write list? It doesn't actually write any user data to disk, it actually doesn't write anything, all it does is play with the amount of space allocated for the given fd on the storage device. I don't really care either way, this just struck me as odd and I want to make sure you have a good reason (hint: add it to the patch description).

On Mon, Oct 16, 2017 at 4:31 PM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > On Monday, October 16, 2017 3:10:59 PM EDT Paul Moore wrote: >> On Thu, Oct 12, 2017 at 11:24 PM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: >> > The audit subsystem allows selecting audit events based on watches for >> > a particular behavior like writing to a file. A lot of syscalls have >> > been added without updating the list. This patch adds 2 syscalls to the >> > write filters: fallocate and renameat2. >> > >> > Signed-off-by: sgrubb <sgrubb(a)redhat.com&gt; >> > --- >> > >> > include/asm-generic/audit_dir_write.h | 4 ++++ >> > include/asm-generic/audit_write.h | 3 +++ >> > 2 files changed, 7 insertions(+) >> >> FWIW, I expect that this syscall list is almost always going to be out >> of date; it's just the way this feature is designed. That doesn't >> mean I'm not going to merge fixes, I just want to make sure >> expectations are set accordingly. > > I understand...but we are years behind. I just wanted to close the gap on a > couple obvious syscalls since everyone else is busy with more important bugs. No worries, I'm perfectly fine with chipping away at things, I just wanted to make sure that people aren't expecting this to be current. The way it's designed I can almost guarantee it will always lag. >> I don't really care either way, this just struck me as odd and I want to >> make sure you have a good reason (hint: add it to the patch >> description). > > Understandable. But its close enough to ftruncate that I think it qualifies. That's fine, I didn't feel very strongly about it either way. I'll merge this tomorrow when I'm back in front of the system with my audit kernel repo.