Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 07 Oct 2009 14:08:40 -0600
From:      Jamie Gritton <jamie@FreeBSD.org>
To:        Rick Macklem <rmacklem@uoguelph.ca>
Cc:        stable@FreeBSD.org, Marcel Moolenaar <xcllnt@mac.com>, Robert Watson <rwatson@FreeBSD.org>, "current@freebsd.org mailing list" <current@FreeBSD.org>
Subject:   Re: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS related?)
Message-ID:  <4ACCF548.2070200@FreeBSD.org>
In-Reply-To: <Pine.GSO.4.63.0910061918380.503@muncher.cs.uoguelph.ca>
References:  <FD184B4B-517F-470E-BAC8-DD0795983C2B@mac.com> <4ABD4BB9.1030804@FreeBSD.org> <alpine.BSF.2.00.0909270045590.31373@fledge.watson.org> <Pine.GSO.4.63.0910061918380.503@muncher.cs.uoguelph.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
Rick Macklem wrote:
> On Sun, 27 Sep 2009, Robert Watson wrote:
>> On Fri, 25 Sep 2009, Jamie Gritton wrote:
>>
>>> It seems to be NFS related.  I think the null pointer in question is 
>>> from the export's anonymous credential.  Try the patch below and see 
>>> if it helps (which I guess means run it overnight and see if it 
>>> crashes again).  I've also patched a similar missing cred prison in 
>>> GSS_SVC, since I'm not versed enough in NFS/RPC stuff to know if it 
>>> might be the problem.
>>
>> This is one of the reasons I really dislike "magic" credentials and 
>> special handling of NULL credentials -- they always get into code the 
>> author doesn't expect, and either there are bad pointer dereferences, 
>> or incorrect security decisions.  It's almost always the case that a 
>> correct credential should have been cached or generated at some 
>> earlier point to represent the security context...
>>
> I don't really understand prisons/jails, but would creating these
> credentials via:
>     crdup(td->td_ucred); // duplicating the daemon thread's cred
>     - and then replacing the <uid,gids>
> make sense as an alternative to starting with crget()?
> (ie. All the other stuff except <uid,gids> would be "inherited" from the
> credential for the daemon thread.)

That sounds right to me for cases when the cred is based on passed
UID/GIDs. Perhaps you'd want to use the UID-changing helper functions on
kern_prot.c, or perhaps a new helper or helpers just for the circumstance.

- Jamie



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ACCF548.2070200>