On Wed, Oct 12, 2016 at 2:02 PM, Steve Grubb <sgr...@redhat.com> wrote:
> On Thursday, August 18, 2016 2:47:33 PM EDT Richard Guy Briggs wrote:
>> Add sessionid_set field option from kernel uapi macro SESSIONID_SET to
>> enable specifying that sessionID is set or not in user filters.
> Is there any compelling reason to support two differents fields that 
> essentially
> decide how to audit sessions? I think its a bit clunky to expect that people
> write rules
> -a always,exit -S open -F path=/path/file  -F sessionid>0
> but if you want to record daemons, then its not as simple as using -1 which is
> what is in the logs and the intuitive answer. Instead you have to use a new
> field.
> -a always,exit -S open -F path=/path/file  -F sessionid_set=0
> But then you can also do the first rule as:
> -a always,exit -S open -F path=/path/file  -F sessionid_set=1
> So, we have 2 ways of doing almost the same thing. I don't really like this.

I originally thought the loginuid_set filter functionality was added
to satisfy a request made by you for the audit userspace; I suggested
to Richard that we do the same for the session ID since there were
some definite similarities.  However, having looked back at the
original motivation for adding the loginuid_set functionality, I don't
we will face the same problem with the session ID.  If Richard can't
think of any compelling reason to keep a dedicated sessionid_set
filter, I think we can drop it.

Further, while I understand why Eric B. needed to make the internal
audit kernel changes to the loginuid code (and other audit UID/GID
bits for that matter), I'm less convinced on the need to change the
kernel/userspace filter API to add the loginuid_set capability.
However, that was before my time, and it's done now, we can't yank it
out at this point.

paul moore

Linux-audit mailing list

Reply via email to