Re: [PATCH 2/5] Rework stubs in security.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Tony Jones ([email protected]) 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
-
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]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux