Date: Fri, 8 Nov 1996 16:02:43 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@FreeBSD.org, john@starfire.mn.org Subject: Re: Strange messages from my 2.1.0 kernel Message-ID: <199611082302.QAA12772@phaeton.artisoft.com> In-Reply-To: <199611082214.XAA07826@uriah.heep.sax.de> from "J Wunsch" at Nov 8, 96 11:14:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > fhtovp: file start miss 1946157056 vs 68 > > > > > > It might mean you have two nfsnodes pointing to the same vnode... > > > Or it might mean someone is trying to NFS hack your system... > > > Or it might be an mmap() of an NFS file on an FS with a 4k block > > > size and an NFS rzise/wsize of 8K, or vice versa... > > Or it might be that Terry forgot to use grep(1), so he didn't notice > that these messages are from cd9660 f/s... Actually, the cd9660 code > is by far too blatant in spitting out kernel printf's whenever it is > going to reject a request with a ``stale file handle'' response. Or it might be that the NFS VFS consumer is broken and the vfs_syscalls.c VFS consumer isn't broken, and the two operate differently because the code which should be shared isn't. And it may be that a broken VFS consumer is the only thing that can trigger that. And it may be that Terry knew that already... 8-). > > Oh! OK! That makes perfect sense, then. A remote system had had > > my CD NFS mounted, but I rebooted, and my CD does not get automatically > > booted on mount (I hate to automatically mount removeable media). > > Why do you hate this? Because someone (IMHO stupidly) made a failure > mounting a CD-ROM a fatal error? This can easily be avoided (and i do > avoid it). I always disliked this idea. > > Simply reorganize your /etc/rc so that only mount failures for > filesystems that are essential for you will abort the script. Take > away the `noauto' for the CD-ROM, and simply try mounting it at boot > time. If it's not there, /etc/rc will go on without complaints > (except from mountd later about not being able to change the NFS > export attributes for /cdrom, but that's benign). Or maybe he hates it because NFS should export a directory vnode and all inferior nodes of the same dev_t value, and the NFS exports processing doesn't belong in each FS's mount code (which is what makes you mount the thing before you can export it). And maybe if the cdrom is there, it should be mounted on a directory that the user has mapped for the label, and not mounted if it's not, and never affect NFS at all... like the transient resource it is. And maybe the namei() code should always use a relative root instead of only conditionally using one, so that if the the isn't mounted, I don't have to conditionally not export the mount point so that I don't open a nice security hole for valid NFS users to use fraudulent file handles to escape further up in the directory tree on the device (which since it isn't a mounted CDROM, is the node on the FS that the CDROM would have covered had it been successfully mounted). And then the NFS daemon can set the relative root prior to VOP_LOOKUP so that it's no longer a problem. So maybe it's a security issue which doesn't change even if the removable media didn't fatally fail the boot on a failure to mount. You think? Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611082302.QAA12772>