Date: Sat, 13 Jul 1996 21:03:16 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, adam@veda.is Subject: Re: strangest weirdness Message-ID: <199607140403.VAA06010@phaeton.artisoft.com> In-Reply-To: <199607130821.KAA22966@uriah.heep.sax.de> from "J Wunsch" at Jul 13, 96 10:21:11 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I have also noticed that executables dump core often on client machines when > > the files on the fileserver have been updated "under their feet". Okay I know > > "if it hurts, don't do that", but why do these glitches occur? > > Terry will certainly jump in now and explain you that it would be > better to move over the entire executable into local swap instead of > relying on the ability to page it in from the NFS server. The latter > is what we're doing right now -- so you are simply not expected to > remove it on the server. The Unix semantics of ``a file will only be > removed once the last reference to it disappeared'' don't work over > NFS since the server simply doesn't know (and cannot know due to the > statelessness of the protocol) which clients still hold references on > some file. These semantics are being emulated in the case where you > unlink a file on the client that has still other references, by > renaming the file on the server first, and remove it later. Actually, you could implement a simple distributed cache coherency protocol for executables with a slight modification of the rpc.statd code in current and a minor change to the NFS client. It wouldn't be an NFS spec compliant implementation afterwards, but it would solve the problem. I would like to see a flag in the mount structure for FS's which is inherited from the FS type, so that the dev of an inode about to be exec'ed may be dereferenced through the mount struct to decide if the image is coming from local stable storage, local removable storage, or network storage. I would also like to se an option where an executable image could be forced into local memory. If swap is available, it would be considered to be local memory. I would like to see a default of the current behaviour, with sysctl based controls to cause the exec to force the image into local memory in the local removable media case or the network storage case, or both, under user configuration. To solve your problem (and for my personal defaults selection), you would set the flag for the exec from network storage case. Mach, Linux, SunOS, Solaris, SVR4, SCO Xenix, etc., all have the behaviour of using an image for swap store, and when the image is modified without notification (the image is modified on the NFS server case) or when the image is "deleted" without notification the CDROM/floppy removal case), the client system is the one that suffers. What makes this particularly onerous in NFS is that one NFS client can intentially crash another NFS client of the same server, given knowledge of what programs are running and a writable server store. In addition, this method can be used to hack an otherwise secure client, typically by rewriting the target page on the server so that when the accept completes on sendmail, it throws up a shell, or something similar. Sendmail is SUID root, so it is a bad example, but telnetd (/usr/libexec/telnetd) is a good candidate for this hack, since the ruserok() does not specifically block vouchsafe for "bin", only for "root", and telnetd is owned by "bin". Since this bin owned binary will be run by root (inetd) on a client connect, it is an ideal place to hack. Besides the security issues, it's just plain annoying to have the client quit functioning, or hang pending a pagin from the server when the server has gone down (diskless/dataless configurations of SunOS are frequently sworn at for this failing). 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?199607140403.VAA06010>