Re: [RFC] vfs: cleanup of permission()

[Sam Vilain <sam@vilain.net>]

tvrtko.ursulin@sophos.com 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/