Subject: Re: CVS commit: src/sys
To: Alistair Crooks <firstname.lastname@example.org>
From: Elad Efrat <email@example.com>
Date: 06/23/2007 18:23:44
Alistair Crooks wrote:
> On Sat, Jun 23, 2007 at 01:15:21PM +0300, Elad Efrat wrote:
>> David Laight wrote:
>>> Module Name: src
>>> Committed By: dsl
>>> Date: Sat Jun 23 09:02:13 UTC 2007
>>> Modified Files:
>>> src/sys/kern: kern_auth.c
>>> src/sys/sys: kauth.h
>>> Log Message:
>>> Simplify the interfaces needed for sys_setgroups() and sys_getgroups().
>>> Exposed that the kauth code holds groups in an array, but removes some
>>> of the knowledge of the maximum number of groups.
>>> Allows the syscall code to copyin/out directly to/from the cred structure,
>>> this save a lot of faffing about with malloc/free even when compat code
>>> has to use 16bit groups.
>>> To generate a diff of this commit:
>>> cvs rdiff -r1.47 -r1.48 src/sys/kern/kern_auth.c
>>> cvs rdiff -r1.37 -r1.38 src/sys/sys/kauth.h
>>> Please note that diffs are not public domain; they are subject to the
>>> copyright notices on the relevant files.
>> you are changing a critical kernel interface. where was this brought up
>> for discussion?
> AFAICT, kauth is unmaintained right now.
> It would be a pity if it were to bitrot - no-one wants that.
I don't understand how kauth not being maintained means it's okay to
expose its internals.
question to you, al, as a core member and tnf president: will it be
as easy as it was to implement various security models on top of kauth
now that its internals have been exposed?
does "compat code with one less malloc" weighs more than "opaque and
abstract interface allowing various pluggable secmodels"?
to users: the commit in question means that the internals of kauth have
been exposed, severely limiting the flexibility of the interface. if it
was possible to say "kauth allows different secmodels to be implemented
and used in netbsd", after the commit it means "back to stone age".