From owner-p4-projects@FreeBSD.ORG Thu May 5 16:06:41 2005 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 295BC16A4D0; Thu, 5 May 2005 16:06:41 +0000 (GMT) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1A2616A4CE for ; Thu, 5 May 2005 16:06:40 +0000 (GMT) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE87243DC2 for ; Thu, 5 May 2005 16:06:40 +0000 (GMT) (envelope-from csjp@freebsd.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.1/8.13.1) with ESMTP id j45G6eOc061804 for ; Thu, 5 May 2005 16:06:40 GMT (envelope-from csjp@freebsd.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.13.1/8.13.1/Submit) id j45G6e5W061801 for perforce@freebsd.org; Thu, 5 May 2005 16:06:40 GMT (envelope-from csjp@freebsd.org) Date: Thu, 5 May 2005 16:06:40 GMT Message-Id: <200505051606.j45G6e5W061801@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to csjp@freebsd.org using -f From: "Christian S.J. Peron" To: Perforce Change Reviews Subject: PERFORCE change 76561 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2005 16:06:41 -0000 http://perforce.freebsd.org/chv.cgi?CH=76561 Change 76561 by csjp@csjp_xor on 2005/05/05 16:05:39 Fix long standing kernel panic associated with NFS. The problem stems from dispatching VOP_GETATTR from the kernel using NOCRED. The NFS subsystem will dereference ucred when forming the NFS request resulting in a panic. I have changed the code to use the calling credential of the user in order to retrieve information about the file. However this in itself is fairly futile in that NFS does not support extended attributes. While this change should not do any harm, a more long term fix would be to implement an efficient way to check the capabilities of the files system. Affected files ... .. //depot/projects/trustedbsd/mac/sys/security/mac_chkexec/mac_chkexec.c#5 edit Differences ... ==== //depot/projects/trustedbsd/mac/sys/security/mac_chkexec/mac_chkexec.c#5 (text+ko) ==== @@ -204,10 +204,11 @@ struct vcache_fs *vfc; struct vattr va, *vap; int error; + struct thread *td = curthread; /* XXX */ ASSERT_VOP_LOCKED(vp, "mac_chkexec_get_fs_cache: no vlock held"); vap = &va; - error = VOP_GETATTR(vp, vap, NOCRED, curthread); + error = VOP_GETATTR(vp, vap, td->td_ucred, td); if (error) return (NULL); mtx_lock(&cache_mtx); @@ -239,6 +240,7 @@ struct vcache *vcp; int error; struct vattr *vap, va; + struct thread *td = curthread; ASSERT_VOP_LOCKED(vp, "no vlock held"); if (!mac_chkexec_cache) @@ -249,7 +251,7 @@ if (vfc == NULL) return; vap = &va; - error = VOP_GETATTR(vp, vap, NOCRED, curthread); + error = VOP_GETATTR(vp, vap, td->td_ucred, td); if (error) return; vcp = uma_zalloc(cache_zone, M_WAITOK); @@ -284,13 +286,14 @@ struct vcache_fs *vfc; struct vattr *vap, va; int error; + struct thread *td = curthread; ASSERT_VOP_LOCKED(vp, "no vlock held"); vfc = mac_chkexec_get_fs_cache(vp); if (vfc == NULL) return; vap = &va; - error = VOP_GETATTR(vp, vap, NOCRED, curthread); + error = VOP_GETATTR(vp, vap, td->td_ucred, td); if (error) return; vc.fileid = vap->va_fileid; @@ -319,12 +322,13 @@ int error; struct vcache_fs *vfc; struct vattr va, *vap; + struct thread *td = curthread; if (!mac_chkexec_cache) return (NULL); ASSERT_VOP_LOCKED(vp, "no vlock held"); vap = &va; - error = VOP_GETATTR(vp, &va, NOCRED, curthread); + error = VOP_GETATTR(vp, &va, td->td_ucred, td); if (error) return (NULL); vfc = mac_chkexec_get_fs_cache(vp);