[PATCH 1/1] audit: Add new syscalls to the perm=w filter

[Paul Moore]

On Mon, Oct 16, 2017 at 4:47 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> 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 at redhat.com>
>> >>
>> >> Reviewed-by: Richard Guy Briggs <rgb at redhat.com>
>> >
>> > 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.

It really depends on the situation, there is no strict rule to follow,
although if I'm expecting you to respin a patch I'll let you know.  In
the comment above I said that I didn't care either way (about the GH
issue), that means you don't need to worry about it.  I also said I'd
fixup your sign-off line when I apply the patch, there is no need to
respin, although you do need to fix that from this point on (future
new patches as well as any I ask you to respin).

In general, heavy editing by the maintainer is discouraged; exceptions
are made for merge fuzz, trivial fixes, agreed upon tweaks, etc.
There is also a bit of a human factor if we are truly honest, but I
try to minimize that as much as possible (am I in a good mood and
wiling to fix the code?  has the contributor annoyed me lately?
etc.).  At the end of the day, every maintainer is a bit different.

-- 
paul moore
www.paul-moore.com