* Tony Jones (tonyj@private) wrote:
> The discussion about composing with commoncap made me think about whether
> this is the best way to do this. It seems that we're heading towards a
> requirement that every module internally compose with commoncap.
Not a requirement, it's a choice ATM.
> If so (apart from the obvious correctness issues when they don't) it's work
> for each module and composing N of them under stacker obviously creates
> overhead.
>
> Would the following not be a better approach?
>
> static inline int security_ptrace (struct task_struct * parent, struct task_struct * child)
> {
> int ret;
> ret=cap_ptrace (parent, child);
> #ifdef CONFIG_SECURITY
> if (!ret && security_ops->ptrace)
> ret=security_ops->ptrace(parent, child);
> #endif
> return ret;
> }
Heh, this was next on my list. I just wanted to separate the changes to
one at a time so we can easily measure the impact. This becomes another
policy shift.
> If every module is already internally composing, there shouldn't be a
> performance cost for the additional branch inside the #ifdef.
This needs measurement to verify.
> I havn't looked at every single hook and it's users to see if this would
> cause a problem. I noticed SELinux calls sec->capget() post rather than pre
> it's processing which may be an issue.
Yes, that need careful inspection.
thanks,
-chris
This archive was generated by hypermail 2.1.3 : Fri Aug 26 2005 - 11:00:32 PDT