[ ... ] >> For example:
>> time->Thu Apr 17 07:58:44 2014 >> type=CONFIG_CHANGE msg=audit(1397717924.255:37148): op="remove rule" >> dir="/boot" key="pkg-s" list=4 res=1 >> time->Thu Apr 17 07:59:04 2014 >> type=CONFIG_CHANGE msg=audit(1397717944.762:37151): op="remove rule" >> dir="/opt" key="pkg-s" list=4 res=1 >> time->Thu Apr 17 10:01:02 2014 >> type=CONFIG_CHANGE msg=audit(1397725262.301:37157): op="remove rule" >> dir="/fs/sozan/loc64-u12" key="pkg-l" list=4 res=1 >> time->Thu Apr 17 10:01:02 2014 >> type=CONFIG_CHANGE msg=audit(1397725262.301:37156): op="remove rule" >> dir="/fs/sozan/loc32-el5" key="pkg-l" list=4 res=1 > [ ... ] device and inode information. This is, technically, > what your watch is on. If the inode disappears, then the rule > is ejected. Rules can survive across renames but not > deletions. > I don't know what is managing your system, but its probably > deleting paths. I am the sole user (as far as I know...) of both systems, and I am pretty sure I was asleep at least at some of the reported times, and I can't imagine any of the system scripts deleting and recreating '/boot' and '/opt', for example. Also I checked the 'm' times of '/' and '/fs/sozan' and they are a few weeks old. None of the "disappeared" paths seems to have been modified in any way. BTW this has happened also on a far smaller scale on a Debian 7/Wheezy system. Again a system where I am the sysadm and only user, and it seems roughly at the same time as a treewalk. The vague impression I have in both cases is that there is some reason why under high load 'audit' just loses or deletes watches. Note that this was not under high _logging_ load, because the watches for '/opt' and '/boot' are to log in case of writing or attribute changes, and the treewalk is entirely (on one side) read-only. Indeed I see not even a trace of logging about those accesses. Anyhow, I have now recorded the inos of the watched directories, and I shall also run 'inotifywait -m /' to catch if possible any changes in '/opt' and '/boot'. -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
