On 09/10/2013 09:25 AM, Joshua Brindle wrote: >> You didn't include my two changes. Was that because you didn't agree >> with them or you just wanted to keep them separate? >> > > I don't normally pull peoples patches into my own :) I can do that if > you want.
As my changes are essentially bug fixes (one for your code, one for Bill's), I'm fine with folding them, and they are public domain so that isn't a problem. > I'd rather it work the same way upstream auditd works. Ok. I actually retried the -e 1 approach and it still seems to run up against EAGAIN errors so I'm not clear on what is happening there. So directly calling audit_set_enabled() as in my patch seems the better route. I also seem to get errors if I try to include more than one watch rule, I/auditd ( 119): Starting up I/audit_log( 119): Previous audit logfile detected, rotating E/audit_rules( 119): -w /data/system -p wa E/audit_rules( 119): -w /data/security -p wa E/audit_rules( 119): Unknown permission I'm guessing that is a bug in your parser? > Yes, but it looks like the auditd gerrit review has been rejected. > Should I submit anyway? Not rejected (not a CR-2) but just doesn't verify against Google internal tree. That's ok; it just means that they have to resolve it internally. Once you resolve the above error/bug, I'd suggest that you go ahead and upload it as a new change relative to Bill's change. > I also originally had audit.rules in /data/security but one of my phones > has that set to 0700 owned by system so auditd couldn't read it. I'd > rather it be there (and possibly included in the bundles we are talking > about elsewhere). On AOSP master and on our seandroid* branches, /data/security is 0711. But it shipped in android-4.3_r1 as 0700. Not sure yet about whether we can/should add more files there or to the SELinuxPolicyInstallReceiver. We could always have a separate ConfigUpdateInstallReceiver instance that handles audit.rules and drops them to /data/misc/audit. They have similar receivers for /data/misc/keychain, /data/misc/sms, and /data/misc/zoneinfo (see frameworks/base/services/java/com/android/server/updates). Only reason to make it part of the SE bundle is if we expect it to become coupled, e.g. audit rules written in terms of SELinux contexts, which I suppose is possible. -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe seandroid-list" without quotes as the message.
