From owner-freebsd-arch Tue Apr 3 14:29:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 07C3A37B71C; Tue, 3 Apr 2001 14:29:54 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f33LTmj70619; Tue, 3 Apr 2001 14:29:48 -0700 (PDT) (envelope-from dillon) Date: Tue, 3 Apr 2001 14:29:48 -0700 (PDT) From: Matt Dillon Message-Id: <200104032129.f33LTmj70619@earth.backplane.com> To: Robert Watson Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Eliminate crget() from nfs kernel code? References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :While extending ucred in a rewrite of my mandatory access control :implementation on FreeBSD, I managed to panic the system: : :... : :What I discovered was that the nfs_statfs() implementation fakes up a :credential using crget() to use when invoking nfs_fsinfo(), and uses it :only for the lifetime of the nfs_statfs() call. While I don't claim to :have a complete understanding of the NFS code, it appears that this is :done in lieu of using p->p_ucred, and that other related VFS calls are :passed a ucred as an argument. This causes some problems for :implementations of extensions to ucred, as it introduces a new (and fairly :arbitrary) credential that must be created to satisfy the need to call :crget() here. I was wondering if someone could expound on the rationale :for creating a new (and fairly poorly initialized) ucred in this scenario, :and perhaps comment also on two possible work-arounds: : : 1) Use p->p_ucred. : 2) Introduce a ucred argument to vfs_statfs() to be used by : file system implementations that require it. :... :ucred argument (although this will break binary compatibility in -CURRENT, :which is where I'd consider doing the change). The effect of the current :code, btw, is to always make NFSPROC_STATFS() calls using uid/gid of 0 :(possibly mapped to nobody on the server), rather than the calling process :-- it's possible to imagine environments in which this is inappropriate, :especially with the introduction of MAC. I notice that there's some :similar behavior in the ncp code. : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project :robert@fledge.watson.org NAI Labs, Safeport Network Services Hmm. It's hard to say. The standard doesn't say anything about the credential needing to be root/wheel over the wire for statfs(), but if we change it we will probably break someone somewhere. I think you want to keep crget()/crfree() if possible, just so you don't have to worry about the data being sent over the wire breaking some poor sod. But if you want to bite the bullet and use the process ucred I'd say go for it - keep a careful watch for complaints of FreeBSD suddenly failing against various NFS servers though. The fake ucred has been in the NFS codebase from day 1. It could very well be outdated now. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message