--DSayHWYpDlRfCAAQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 18, 2007 at 02:10:23PM +0000, David Laight wrote:
> The kauth code seems to be full of wrapper functions.
>=20
> In particular every peice of code that needs to look at one of the
> process's uids ends up calling a function.
> This might be reasonable for LKMs, but for code that is linked into the
> main kernel image rather OTT.

That's rather the point of kauth. It's supposed to be the only code area=20
that actually knows what a credential is, so that it can change them as=20
desired. If you want to know something, you have to ask it.

I also don't see how LKM vs main kernel matters. Part of the idea is that
we can add new security domains (hope I used the right term) as needed. So
while code was compiled into a kernel at inital link (and thus could know
all about the domains in use at that time), the actual credential code in
use may well be inan LKM itself, and thus the kernel code is in the same=20
boat as any LKM-consumer of kauth info.

> Of course, this involves making the structure in kauth_impl.h publicly
> visible :-)

Which would, IMNSH opinion would be a BAD thing. :-)

I agree that the opacity arguement is weaker for uid, but I believe it is=
=20
still important.

There also is the practical arguement that we can't exponse uid w/o=20
exposing everything else, and other things REALLY need to stay opaque.

Take care,

Bill

--DSayHWYpDlRfCAAQ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFF2L+cWz+3JHUci9cRAojAAKCGdAZCeGQ6z24ZIm2CIAjGQqdeEQCeI+A9
wIYDUBczwhrRfar21EzxPF8=
=m0lJ
-----END PGP SIGNATURE-----

--DSayHWYpDlRfCAAQ--