Adding multiple watch rules on same path

Hi Steve,
As I was running some of our watch tests, I noticed the following:
You can add multiple watches on the same path if you specify different filter key values. That doesn't make sense to me, so I wanted to check if that is an intended behavior? and if so why?

Also, since you can have multiple watches on same path, it is no longer sufficient to do a "-W <path>" to remove the watch, now you have to specify which watch to remove by using the "-k key" as well. Is this is how auditctl will remain to function, because we need to make changes to our functions accordingly

I am on the latest rawhide kernel(2.6.17-1.2573.fc6) and audit-1.2.5-8

[root~]# auditctl -w /tmp/file2
[root~]# auditctl -l
LIST_RULES: exit,always watch=/tmp/file2 syscall=open,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,
chmod,fchmod,chown,fchown,lchown

[root~]# auditctl -w /tmp/file2 -k first-key
[root~]# auditctl -l
LIST_RULES: exit,always watch=/tmp/file2 key=first-key syscall=open,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,
chmod,fchmod,chown,fchown,lchown
LIST_RULES: exit,always watch=/tmp/file2 syscall=open,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,
chmod,fchmod,chown,fchown,lchown

[root~]# auditctl -w /tmp/file2 -k second-key
[root~]# auditctl -l
LIST_RULES: exit,always watch=/tmp/file2 key=first-key syscall=open,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,
chmod,fchmod,chown,fchown,lchown
LIST_RULES: exit,always watch=/tmp/file2 key=second-key syscall=open,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,
chmod,fchmod,chown,fchown,lchown
LIST_RULES: exit,always watch=/tmp/file2 syscall=open,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,
chmod,fchmod,chown,fchown,lchown

[root~]# auditctl -W /tmp/file2
[root~]# auditctl -l
LIST_RULES: exit,always watch=/tmp/file2 key=first-key syscall=open,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,
chmod,fchmod,chown,fchown,lchown
LIST_RULES: exit,always watch=/tmp/file2 key=second-key syscall=open,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,
chmod,fchmod,chown,fchown,lchown

[root~]# auditctl -W /tmp/file2
Error sending delete rule request (No rule matches)
[root~]# auditctl -l
LIST_RULES: exit,always watch=/tmp/file2 key=first-key syscall=open,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,
chmod,fchmod,chown,fchown,lchown
LIST_RULES: exit,always watch=/tmp/file2 key=second-key syscall=open,truncate,ftruncate,rename,mkdir,rmdir,creat,link,unlink,symlink,
chmod,fchmod,chown,fchown,lchown

-Loulwa

I have programmed anything to allow or disallow this behavior. I'm sure there are many many combinations of things that do not make sense together like any field other than -F messagetype when exclude filter is picked. But I have not thought up all combinations of what should and should not be allowed. The logic for that might make auditctl more complex than it need be.

On the otherhand, suppose you wrote a system that dynamically alters the audit rules. You could use the keyfield to identify those rules so that you do not have to think about baseline rules the admin may have in place. IOW, you can issue another rule to watch /etc/shadow for writes without checking to see if it already exists. Also, you can delete the rule without worry that you are deleting something the admin wants there as baseline.

So, I can sort of see a use for it.

I'm undecided about whether to keep the behavior or not. I don't see much harm in it and it might turn out to be useful.

-Steve

I think it's useful to keep it, especially if it already works now. A file may need auditing for multiple overlapping reasons, and it's nice to get consistent results in that case.

It's a feature beyond what CAPP/LSPP requires and it's only available to admins, so there is no need to specifically test these combinations if you're just going for CC compliance.

-Klaus