On Wednesday 15 March 2006 14:14, Loulwa Salem wrote:
Basically .. here is what I am proposing we change in the formatting
..
Unnecessary stray symbols (,:() ..etc surrounded by spaces on both
sides) are a bit inconsistent and problematic (we deal with them
currently, but would be nice to get rid of them and thus the use of all
the exception code to handle them).
I think we might be able to remove a couple. However, since the audit logs
currently have this...we cannot get rid of the exception code anytime soon.
People tend to take tools and use them on older releases.
All two word fields should have an "_" between the words
rather than a
space (since we use the space as a delimeter which makes the most sense,
we end up with lonely words that need to be ignored currently). Using
"_" would make life easier instead.
Might make it tougher too. For example, suppose someone wanted to find auid =
520. The user space object manager, dbus, has a auid of -1, and is not what
we want. The sender auid is what we want. So, by having a space, we still
match the sender auid = 520. The word to the left is to give context to a
human reading the raw record, but the search utility should still match the
auid value even if it has sender before it. If we combine field names, I
think I'll have to maintain a table of field names to types so that ausearch
can make sense of the field's contents no matter what the name is.
Another example to make this more concrete, suppose someone did ausearch -p
200. We have this record with the proposed changes:
type=DAEMON_START msg=audit(1139253971.701:7092) auditd start, ver=1.0.14,
format=raw, auid=4294967295 res=success, auditd_pid=200
The field auditd_pid=200 is clearly a pid. Should this record be a match?
Using the library specs proposed, a programmer would possibly call
ausearch_set_param(au, "pid", "=", "520",
AUSEARCH_STOP_EVENT);
Should they have to specify audit_pid or pid? Should they have to know all the
variations on pid?
-Steve