Re: [AppArmor 38/45] AppArmor: Module and LSM hooks

[Andreas Gruenbacher <agruen@suse.de>]

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