[email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
