Elad Efrat wrote:
> David Laight wrote:
>> On Sat, Jun 23, 2007 at 06:23:44PM +0300, Elad Efrat wrote:
>>> does "compat code with one less malloc" weighs more than "opaque and
>>> abstract interface allowing various pluggable secmodels"?
>>
>> Actually the malloc/free was on every call to sys_set/getgroups,
>> not just those in the compat code.
> 
> how common are calls to syscalls? can you show performance tests that

obviously a very important "the set/getgroups" was omitted here. :)

> indicate a clear measurable system performance improvement as a result
> of removing the malloc/free?
> 
>> One benefit of my changes is that the NGROUPS constant is no
>> longer in the sys_setgroups() functions, possibly allowing it
>> to be dynamically changable (etc) without changing the interface
>> to LKM compat code.
> 
> your changes may introduce this benefit, but are overshadowed by the
> simple fact that you broke a critical kernel interface and exposed its
> internals, eliminating one of its key design goals of opacity -- and
> you did so without any prior discussion.
> 
> while the changes to get/setgroups syscall internals and compat calls
> will not change the user experience in any way, breaking kauth's opacity
> have direct and immediate implications in the form of not allowing much
> flexibility when implementing new security models that expand beyond
> what is currently allowed by bsd44.
> 
> additionally, it is well worth pointing out that the benefit you
> introduced is orthogonal to breaking the interface's opacity, and could
> have been introduced either way.
> 
> -e.