On Monday 13 February 2006 14:33, Matt Anderson wrote:
> You should use suid for sender user id and sauid for sender
audit (login)
> user id.
I can do that, but your still suggesting that the data be contained
inside a string in the audit record. It seems like this is not what we
want since then all of the tools will need to look at that string in
addition to the audit fields where the information is always reported.
I still don't think this is such a big deal. So far there is only ausearch and
aureport, both of which share parsing code.
>>I mentioned this on #audit and Steve said he could add the
ability to
>>ausearch to look for the uid= substring in the message, but I'm not sure
>>that meets the first requirement.
>
> Sure it does. The SAR part means ausearch needs to match on that field.
I know you can make ausearch meet the FAU_SAR requirement, but I don't
see how the kernel side can do selective audits based on a substring
match of the message, and isn't that what FAU_SEL requires?
I was careful with what I was saying. ;)
SEL is a problem. The only high performance way of doing this that I know of
would be to make a new structure to pass this message and the suid & sauid
would be passed. Then we could do the matching on it. Parsing strings in the
kernel does not sound good to me.
Setting the loginuid as Linda suggested would probably be the best answer if
you could do that instead. You'd need to set it at the start of a job saving
away the original and then reset it back upon completion.
>>Does ausearch always have to look into the message string to
>>see if there is a (a)uid there to match on?
>
> This is not a problem. If it doesn't it will. :)
You don't think its a problem for your tool, but any other tools that
would be built to do log reduction or analysis now have to deal with
matching those strings. That doesn't sound bad to you?
I'm going to create a library that these other tools can use. This way if we
change to a binary record, the third party tools do not need to be
re-written.
-Steve