NetBSD Problem Report #38174

From martin@duskware.de  Wed Mar  5 14:47:33 2008
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 33E6863B882
	for <gnats-bugs@gnats.netbsd.org>; Wed,  5 Mar 2008 14:47:33 +0000 (UTC)
Message-Id: <20080305141708.DB19F63B882@narn.NetBSD.org>
Date: Wed,  5 Mar 2008 14:17:08 +0000 (UTC)
From: pooka@iki.fi
Reply-To: pooka@iki.fi
To: netbsd-bugs-owner@NetBSD.org
Subject: kauth_cred_t interpreted outside of kauth
X-Send-Pr-Version: www-1.0

>Number:         38174
>Category:       kern
>Synopsis:       kauth_cred_t interpreted outside of kauth
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 05 14:50:00 +0000 2008
>Last-Modified:  Sat Feb 14 18:30:02 +0000 2009
>Originator:     Antti Kantee
>Release:        
>Organization:
>Environment:
>Description:
NOCRED and FSCRED are being interpreted outside of kauth.
>How-To-Repeat:
grep, especially file system code, e.g:

       if (cred == NOCRED)
                panic("ffs_alloc: missing credential");

>Fix:
Move handling inside kauth.

>Audit-Trail:
From: Elad Efrat <elad@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/38174: kauth_cred_t interpreted outside of kauth
Date: Wed, 05 Mar 2008 17:02:37 +0200

 pooka@iki.fi wrote:
 >> Number:         38174
 >> Category:       kern
 >> Synopsis:       kauth_cred_t interpreted outside of kauth
 >> Confidential:   no
 >> Severity:       non-critical
 >> Priority:       medium
 >> Responsible:    kern-bug-people
 >> State:          open
 >> Class:          sw-bug
 >> Submitter-Id:   net
 >> Arrival-Date:   Wed Mar 05 14:50:00 +0000 2008
 >> Originator:     Antti Kantee
 >> Release:        
 >> Organization:
 >> Environment:
 >> Description:
 > NOCRED and FSCRED are being interpreted outside of kauth.
 >> How-To-Repeat:
 > grep, especially file system code, e.g:
 > 
 >        if (cred == NOCRED)
 >                 panic("ffs_alloc: missing credential");
 > 
 >> Fix:
 > Move handling inside kauth.
 > 
 > 

 Aren't they used to indicate the request is coming from the kernel?

 See kern_auth.c revision 1.17.

 -e.

From: Elad Efrat <elad@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: pooka@iki.fi
Subject: Re: kern/38174: kauth_cred_t interpreted outside of kauth
Date: Wed, 05 Mar 2008 17:16:31 +0200

 Er, possibly I misunderstood.

 Are you interested in replacing these constants and tests with wrapper
 functions like kauth_cred_kernel() and kauth_cred_is_kernel()? :)

 -e.

From: Antti Kantee <pooka@iki.fi>
To: Elad Efrat <elad@NetBSD.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/38174: kauth_cred_t interpreted outside of kauth
Date: Wed, 5 Mar 2008 17:24:46 +0200

 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.

 -- 
 Antti Kantee <pooka@iki.fi>                     Of course he runs NetBSD
 http://www.iki.fi/pooka/                          http://www.NetBSD.org/
     "la qualité la plus indispensable du cuisinier est l'exactitude"

From: Iain Hibbert <plunky@rya-online.net>
To: gnats-bugs@netbsd.org, elad@netbsd.org, pooka@iki.fi
Cc: 
Subject: Re: kern/38174: kauth_cred_t interpreted outside of kauth
Date: Sat, 14 Feb 2009 17:37:22 +0000 (GMT)

 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".  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?

 iain

From: Elad Efrat <elad@NetBSD.org>
To: Iain Hibbert <plunky@rya-online.net>
Cc: gnats-bugs@netbsd.org, pooka@iki.fi
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> 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	PR Database Search