Re: [RFC] Testcase Scenarios for Auditfs Code

On Tue, 2005-04-26 at 10:38 -0500, Loulwa F Salem wrote: I just ran through these testcases by hand (just using normal utilities from a shell) using Tim's #7U3 patch against 2.6.12-rc2-mm1. It might be helpful to distinguish which testcases would yield different behaviors if one were to try using the inode-based syscall filters rather than the name-based watches and think about how you might explain to users when they should use one or the other method and how they differ. Some observations: Should be equivalent to putting an inode-based syscall filter on the file, aside from the specific output fields. Only makes sense for the name-based watches. I think that the closest equivalent for inode-based syscall filter would be to monitor file creation syscalls on the parent directory. This also generates a record for the link(2) call on the watched file. That's what I would expect, but you didn't list it above. Note that an inode-based syscall filter would yield the same result for this particular test, but the inode-based filter would persist across reboots (if loaded by auditd on each boot) unlike the watch (which was only on the original file path, unless you explicitly add the new link name to the watch list). Hence, watch-based auditing differs from inode-based filtering in its persistence of tracking of hard links. And actually, the watch-based auditing of access via the hard link would also cease if the incore inode is evicted under memory pressure and then brought incore again later via the link name, right? So how do you explain to users that the watch _may_ be triggered by subsequent accesses via the hard link (until reboot) but can be lost at any time due to memory pressure? Is that the behaviour you want? Should be equivalent to an inode-based filter on the file, as the hard link will share the same inode. This will also generate records for the link(2) call and the unlink(2) call (and if using rm to delete, it will also generate one for access(2) to check file existence and permissions prior to unlinking). Note that an inode-based syscall filter would generate an audit record upon the access to the hard link since the inode is unchanged. Which behavior will most users want? You said "deleted previously" but included the unlink in your expected output. Regardless, if I include the deletion as part of the operation, I get the expected results as well as the access(2) call due to using rm (1). Naturally, this kind of test (creation of a file at a given name) is specific to the watches, but inode-based syscall filter could be used on file creation syscalls on the parent directory. You included the unlink in your expected output, but not the link(2) call for creating the hard link in the first place. As before, inode- based syscall filter could only be used on the parent directory. Plus access(2) if using rm(1) to perform the deletion. Should be equivalent to an inode-based syscall filter on the file. Distinctive to the watch-based approach; inode-based syscall filter could catch the file creation on the parent directory, but would require some kind of userspace assist to set up the filter on the new file. An inode-based syscall filter would continue auditing on the file. What will the users want? Should be equivalent to an inode-based syscall filter on the file, since the inode is unchanged. An inode-based syscall filter would continue auditing access to the file. What concerns me is unclear/unstable semantics and a lack of a clear subdivision between this mechanism and the inode-based syscall filters: - Auditing may or may not be preserved on hard links when using the watches depending on memory pressure, reboots, or whether the watched name is unlinked; is always preserved for inode-based watches. - Auditing is never preserved for renames when using the watches; is always preserved for inode-based watches. - Auditing is automatically enabled for new files when they are created in watched locations when using watches; requires userspace modification to achieve with inode-based watches. -- Stephen Smalley <sds(a)tycho.nsa.gov&gt; National Security Agency