tvrtko.ursulin@private wrote: > Also, since you are modifying LSM interfaces, why not discuss it on the > LSM mailing list? > > And finally, please don't remove nameidata. Modules out there depend on it > and we at Sophos are about to release a new product which needs it as > well. The plan was to announce the whole thing parallel with the release, > but after spotting your post I was prompted to react ahead of the > schedule. However, I am very busy at the moment so the actual announcment > with full details will have to wait for a week or two. You are treating the per-FS security hooks as if they were VFS security hooks. This was an easy mistake to make, as the appearance of a (struct nameidata*) sure makes it look like a VFS call. However, most functions in the kernel don't pass anything in that nameidata slot. Some (eg, syscalls that work on open FDs) can't, either. So the fact that it does not guarantee VFS context information in all situations means permission() is not a VFS function. ie, we don't disagree with what you're trying to do, but if you want path information then you should be working at the VFS layer, not the FS layer. Perhaps you could first come up with a patch to the LSM base that adds VFS hooks rather than FS hooks and make your new system use those hooks? I think that it might be more obvious where such hooks should go, after applying this patch. What we're aiming for, on the permission() front, is that all system calls, ioctls, etc, call either vfs_permission() or file_permission(). Only those two functions should end up calling permission() directly. Sam.
This archive was generated by hypermail 2.1.3 : Wed Mar 01 2006 - 13:21:14 PST