Hi Mitchell,
Thanks for looking at this.
On Monday 03 April 2006 08:51, Mitchell Blank Jr wrote:
The gcc warning isn't correct (since audit_filter_user() only
looked at
state if audit_filter_user_rules() returned non-zero, in which case 'state'
would have been initialized) However the code was needlessly complex --
audit_filter_user_rules() carefully populated the "enum audit_state *state"
with various value but it's only caller just cares if it's AUDIT_DISABLED
or not.
IIRC, this was done to mirror the filtering of syscalls. I think we discussed
this last June/July. Anyways it was a long time ago.
It's shorter and simpler to just let audit_filter_user_rules()
modify its caller's return value more directly. As an added bonus this
also removes the warning.
Changes to the rule matcher have to be carefully tested just in case something
obscure needs it. In this case, I don't think so since its a user space
originating message.
While I was looking at auditfilter.c I did some other minor cleanup
* const-ified pointers where possible
* both audit_data_to_entry() and audit_krule_to_data() had an unused
variable called "void *bufp" which I removed
* [minor] I changed some variables from "int" to "unsigned int" if
they can't be negative. Since ->field_count is unsigned I think it's
a little cleaner to use an unsigned type to iterate through it
These are good cleanups. In a way, I wished this was 2 patches instead of 1.
I'd take all these cleanups immediately. The other one I'd probably want to
put in the test kernel for a week or two just to make sure nothing relied on
the state.
Thanks,
-Steve