On Monday 11 June 2007 16:33, Stephen Smalley wrote: >From a userland perspective, audit and inotify allow you to specify > watches on pathnames, and those watches trigger actions by the audit and > inotify subsystems when those files are accessed. The kernel mechanism > however is inode-based, not pathname-based; the pathname is merely > looked up when the watch is added and mapped to an inode. That's my > point - why should AA be different? Audit watches are not entirely object based (contrary to what the man page says): with simple file renames the watches sticks with the names; with directory renames, watches below the directory get dropped. That's rather weird, and I would say bad for audit. Inotify really watches objects. I can imagine cases where this is exactly what you want, and others where this is exactly what you don't want -- it's pick your poison. AppArmor deliberately is pathname based. There are good reasons for that, and we really, definitely want this pathname based model, with all its benefits and disadvantages. Arguing that AppArmor shouldn't be pathname based because other parts of the kernel try to balance names vs. objects differently, and not even always the same way either, is pretty narrow-minded. If one thing is clear from this entire discussion, it is that there is no agreement on the One True Model, and different solutions are being used. > Would you really recommend that audit or inotify call d_path() on each > open and glob match the result against a list of audit or inotify watches? I don't remember doing so. Thanks, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html