Date: Mon, 27 Nov 2000 00:52:29 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Peter Wemm <peter@netplex.com.au> Cc: "Brian F. Feldman" <green@FreeBSD.org>, Alfred Perlstein <bright@wintelcom.net>, obrien@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/inetd builtins.c Message-ID: <Pine.NEB.3.96L.1001127004343.36087A-100000@fledge.watson.org> In-Reply-To: <200011270434.eAR4Y7D45315@mobile.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 26 Nov 2000, Peter Wemm wrote: > It sounds like you're asking for getfh(2), fhstat(2), fhopen(2).. Sure, it > is intended for nfs lockd, but is in the base kernel, not part of NFS. Please don't use these functions wherever they may be avoided. They make the unfortunate assumption that it's possible to generate a unique (dev,inode) pair for every file that persists from the perspective of the process reference frame. Right now, that is generally *not* an assumption of the base system, especially in kernel where only the vnode pointer has these properties. Any time you try to use these in an environment where either (a) the local system cannot control the unique identifier name space, or (b) where the real unique identifier namespace is too large for our namespace, you will have problems. For example, (a) in distributed file systems, you have no control over how file system objects are uniquely named, and servers with fail-over (just one example) can reallocate identifiers as they need to (especially in NFSv4). (b) would be that some distributed file systems (notably Coda and AFS, but presumably others given the advent of global distributed file systems) use largely namespaces than our petty pair of 32 bit values -- for example, AFS and Coda both use a unique 96-bit FID to identify files by volume and file ID. Presumably the only really correct solution here is to: 1) Set effective process rights to that of the user in question using setusercontext() 2) Open the file using open() 3) fstat() the file to determine that it is regular and sane 4) Proceed with operations We have high hopes that current use of the getfh() and related syscalls can be migrated to using IFS, which provides many of the same properties (zero namespace lookup cost, etc) without introducing hard to deal-with security properties, as well as not introducing new dependencies on functionality not available (or desirable) in all file systems. It should be noted that the Linux VFS layer has traditionally assumed uniqueness of (device num, inode num) in the kernel, and this results in extremely unfortunate and essentially unavoidable trauma with AFS and Coda. Both implementations hash a 96-bit FID down to the 16-bit device number and 32-bit inode number, and when a collision occurs, you get panics or returning of the incorrect file/directory (!). I'd also like to get rid of the current abusive use of device/inode number in userland by tools like tar (to detect hard links, suffering race conditions among other things) by adding a samefile(fd1, fd2) interface at some point, which compares the vnode pointers. In any case, please do not use these (effectively) file-system dependent routines for functionality that may touch non-FFS file systems (such as NFS, AFS, SMBFS, etc). 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1001127004343.36087A-100000>