On Thu, 26 May 2005, Chris Wright wrote: > > a) Clearer semantics, i.e. being able to trace the flow directly into the > > SELinux code and be able to see exactly what's happening. > > I don't agree at all. If you can't follow a function pointer... I wasn't talking about being able to follow a function pointer, but about being able to see what's happening and not guess at the possible semantics. > > b) Getting rid of LSM hooks which SELinux doesn't use (not sure how many, > > but not a large amount). > > At any rate, neither of these (a, or b) are very strong reasoning for > removal. I'll listen to real ideas on how to improve the semantics of > core interfacing with security module (and no, I don't mean function > pointers, I mean real interface semantics). This is not the entire reasoning for removal, I was specifically addressing burden on core kernel maintainers. There's also issues of inappropriate LSMs being submitted, having an essentially unused infrastructure in the kernel at all, and forcing SELinux to always use a generic infrastructure when it's not always the best way. - James -- James Morris <jmorris@private>
This archive was generated by hypermail 2.1.3 : Thu May 26 2005 - 07:18:56 PDT