NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/38174: kauth_cred_t interpreted outside of kauth
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.
Home |
Main Index |
Thread Index |
Old Index