From owner-cvs-all Tue Oct 23 16:13:56 2001 Delivered-To: cvs-all@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4711A37B401; Tue, 23 Oct 2001 16:13:46 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id f9NNDUB41366; Tue, 23 Oct 2001 19:13:30 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 23 Oct 2001 19:13:30 -0400 (EDT) From: Robert Watson To: Alfred Perlstein Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/nfsclient nfs_lock.c In-Reply-To: <20011023164040.P15052@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 23 Oct 2001, Alfred Perlstein wrote: > * Robert Watson [011023 14:11] wrote: > > rwatson 2001/10/23 12:11:31 PDT > > > > Modified files: > > sys/nfsclient nfs_lock.c > > Log: > > o Add two comments identifying problems with the current nfs_lock.c > > implementation, so that the information doesn't get lost. > > (1) /var/run/lock is looked up relative to the current thread's root > > directory, but it's not clear that's desirable. > > (2) A race condition associated with live credential modification on > > a shared credential is present when privilege is granted for > > the purposes of talking to /var/run/lock. > > I have a hackish idea that may resolve this, would it possible > to run the NDINIT passing the struct thread for init's proc? > > That should avoid the chroot problem and at the same time avoid > the temporary uid problem. > > Can you test this? I'm not entirely certain this is the right solution either, as it asserts that the namespace seen by init is the one relevant to rpc.lockd. With few exceptions, the current "best" practice for setting up a rendezvous between userland processes, the kernel, and a particular tend to fall into the following categiories: (1) A pseudo-device, where the /dev name is a property of either MAKEDEV and rendezvous is coordinated using dev_t, or where the name is a property of devfs and provided by the driver. This is used for a variety of kernel-userland data-spewing, including syslog, pccard, usb, my various audit implementations, Coda and Arla, etc. (2) Name passed to kernel via a designated system call, and the credential cached. This is used for the quota and extended attribute implementations, which pass a name to the kernel, which is pushed down via VFS to the individual file system. The file system performs a name lookup relative to the calling process, and then caches a reference to the vnode of the file, as well as a reference to the credential of the calling process. Future access to the file is performed using that credential, rather than the credential of the process indirectly causing the read or write. (3) Name passed to the kernel via a designated system call, and the credential is not cached. Much like (2), except that the credential used for read and write operations is that of the process indirectly causing the operation. ktrace records are written in this manner, as are accounting records. For this type of kernel I/O, either (1) or (2) seems to be an acceptable model. Arla's XFS kernel module effectively exports VFS via an RPC mechanism to userland (but throw in a notion of a container vnode and kernel name cache) for Arla, but the complexity is relatively high. I'm personally a fan of (2), because as some access control models will mediate individual read and write calls, using a more appropriate credential is appropriate. I suspect over time I'll probably change instances of (3) to (2) to address that problem. I hope to have time to take a stab at (2) this evening for the nfs_lock code, but note there are some complications, in the interests of avoiding races during changes of the fifo vnode. If I do get something done tonight, I'll toss you a patch to look at. BTW, I'm not sure what (if any) weird effects might occur if you use another process for a name lookup. I suspect that some of the current assumptions about process locking might not hold, and would tend to avoid it if only for that reason. Using another process's credential is also concerning, since init could potentially decide to change its credential (although ours doesn't, it's not precluded in the UNIX model). > My apologies for getting so irritated with you the other day about > this, in the future taking the time to guess at a possible solution > might be better than simply complaining about it. No problem. Right now, I'm pretty time-constrained--my primary concern was to make sure that the problems were properly identified and documented so that they didn't get lost before 5.0-RELEASE. In a sense, the timeline for fixing them is less important than making sure they do get fixed. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message