I don't mean a conflict in the implementation. Clearly it is possible
to combine accessfs checks with LSM hooks (indeed, I think this is
the only possible way for accessfs until LSM gets authoritative
hooks - hey, this could be an example project for "authoritative"
advocates :-).
My concern was conceptual: accessfs is just another mechanism for
access control to various ressources. As I understand it, LSM is
intended to move /all/ access control logic into separate modules with
a uniform interface to the kernel, so that you can choose whatever
access control mechanism you want (or even rip out all access control,
as for example some embedded applications don't need it). Clearly it's
a long way until LSM actually gets to this point, but nevertheless
it's the overall goal of the whole effort IMHO.
Moving accessfs to use LSM hooks means only changes at the
implementation level, no changes of the concept or user interface of
accessfs are needed. What I wanted to express was only that the LSM
effort may put some constraints on the timeline for kernel inclusion
of accessfs ("collide" vs. "conflict" ;-).
> This patch looks nice, I like it.
I totally agree with that. Maybe I should have expressed it more
clearly in my first mail ;-)
Andreas
-- Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG --------------------------------------------------------- +49 521 1365800 - af@devcon.net - www.devcon.net - 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/