On Fri, 2006-02-03 at 14:51 -0600, Dustin Kirkland wrote:
And carrying around these SIDs as opposed to the string contexts
should
provide enough of an efficiency benefit to merit reworking it as you
propose?
Carrying the SIDs gives you the option of passing them to SELinux so
that it can immediately look up the context structure and perform
comparisons, extract values, etc w/o needing to re-parse the context
string. But you may still need to carry the context strings to avoid
allocation failures at the end when it is too late to abort the
operation.
Ok, so requesting from SELinux the individual user or role or type
string as opposed to getting the entire label and having audit slice and
dice it up? If that's what you mean, I may be able to salvage a good
bit of my patch, which would be nice.
Given that we need to precompute a MLS context struct when the audit
filter rule is inserted anyway (so that we can later do efficient
comparisons of MLS levels), we might want to do this for all of the
fields, eliminating string comparisons entirely at audit filter
evaluation time. See my description of the step-by-step approach for
the MLS case in my earlier response to Steve.
Ok, I understand. I think Steve was going to talk to James Morris
to
see if he has any cycles. Otherwise, I'll start looking into it on
Monday. I'm just afraid that in the time it will take you and others to
review my code for these new SElinux api's, you might have been able to
write better api's anyway.
Possibly, but that doesn't create a larger pool of people who can
contribute in the future to the project...
--
Stephen Smalley
National Security Agency