Re: kern/38174: kauth_cred_t interpreted outside of kauth

[Elad Efrat <elad%NetBSD.org@localhost>]

The following reply was made to PR kern/38174; it has been noted by GNATS.

From: Elad Efrat <elad%NetBSD.org@localhost>
To: Iain Hibbert <plunky%rya-online.net@localhost>
Cc: gnats-bugs%netbsd.org@localhost, pooka%iki.fi@localhost
Subject: Re: kern/38174: kauth_cred_t interpreted outside of kauth
Date: Sat, 14 Feb 2009 20:29:45 +0200

 Hey,
 
 On Sat, Feb 14, 2009 at 7:37 PM, Iain Hibbert 
<plunky%rya-online.net@localhost> wrote:
 > Antti Kantee wrote:
 >>
 >> On Wed Mar 05 2008 at 17:16:31 +0200, Elad Efrat wrote:
 >> > Are you interested in replacing these constants and tests with wrapper
 >> > functions like kauth_cred_kernel() and kauth_cred_is_kernel()? :)
 >>
 >> Something like that.  Although I don't know if it makes any sense to
 >> have explicit routines than rather just interpret the values in the
 >> existing kauth interface routines.
 >
 > I agree. I just had to fix up miscfs/umapfs/umap_vnop.c because it didn't
 > handle the case of "cred == FSCRED".
 
 I believe problems of this kind may exist elsewhere, see
 http://mail-index.netbsd.org/tech-kern/2002/10/22/0021.html (I just
 checked and I *think* the code in question was not modified and still
 may dereference NOCRED/FSCRED, if these values can get there through
 today's code paths).
 
 (Note that nobody answered Matthias's question about the NOCRED/FSCRED
 semantics either.)
 
 Ideally, I'd like to be able to tell where we use NOCRED/FSCRED and
 for what purposes. I'm pretty sure we can use "real" privileges in
 some of the places, if not all of them... maybe contact the authors of
 code that uses them and ask what the point was, if it isn't obvious,
 and why in some cases they are used over available credentials in the
 same context. You will be happy to hear that some of it goes all the
 way back to the "merge with lite2" commits. :)
 
 > If FSCRED and NOCRED are recognised
 > values for an obscured type, the kauth routines should handle them
 > appropriately. ie
 >
 >        cred = kauth_cred_dup(orig);
 >
 >                ...
 >
 >        kauth_cred_free(cred);
 >
 > should not cause a page fault, and requiring all client code to know of
 > special exceptions is hardly different than putting 'if (uid == 0)'
 > everywhere..
 >
 > If its too much work to do that where both are absolute defined values, it
 > could be possible to use a global credential of that name, created at init
 > time?
 
 I won't be objecting to it, but can't say I think it's the right or
 wrong approach until I know we definitely need (or don't need)
 NOCRED/FSCRED in all of the locations they are currently at.
 
 But a global credential will prevent page faults, yes. :)
 
 -e.