Date: Fri, 7 Jan 2000 08:50:04 -0800 (PST) From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/14709: umountall requests possibly mishandled by mountd(8) Message-ID: <200001071650.IAA95996@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/14709; it has been noted by GNATS. From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> To: freebsd-gnats-submit@FreeBSD.org, cjc@cc942873-a.ewndsr1.nj.home.com Cc: Subject: Re: bin/14709: umountall requests possibly mishandled by mountd(8) Date: Fri, 7 Jan 2000 11:46:47 -0500 (EST) [Sorry for the HTML damage lynx did to this.] > Confidential > no > > Severity > serious > > Priority > medium > > Responsible > freebsd-bugs@FreeBSD.org > > State > closed > > Class > sw-bug > > Submitter-Id > current-users > > Arrival-Date > Thu Nov 4 09:50:00 PST 1999 > > Closed-Date > Sat Dec 18 15:39:26 PST 1999 > > Last-Modified > Sat Dec 18 15:39:26 PST 1999 > > Originator > Crist J. Clark cjc@cc942873-a.ewndsr1.nj.home.com > > Release > FreeBSD 3.3-STABLE i386 > > Environment > > FreeBSD 3.x system with mountd(8) running. > > Description > > Several users have reported (search the -questions mail >archive on the string 'umountall' for a sample) strange messages of >the form, > >mountd[<pid>]: umountall request from <IP> from unprivileged port > >Where <IP> is an IP address of the host (not the loopback, however) >appearing in their messages log. No events taking place on the server >in question seems to correlate the the messages. > > I have been able to build a very strong correlation between >the messages and other computers on the local network being shutdown >(see the mail archives, > >http://www.freebsd.org/cgi/getmsg.cgi?fetch=1737357+1744288+/usr/local/www/db/text/1999/freebsd-questions/19991017.freebsd-questions > >for some examples from my personal logs). > > I believe that when machines broadcast their impending >shutdown to the network, the mountd(8) process produces these >messages. The messages worry me for two reasons, > >(1) The server is reporting a request from _itself_ rather than the > machine in question. This means that the server is either spoofing > itself (very bad) or is trying to talk to itself on an > unpriviliged port and failing (why would it do that?). > >(2) The machine that generates the umountall need not actually have > mounted a filesystem from the server. In fact, in the example I > referenced above, only one of the machines that caused a message > by going down actually had mounted anything from the server. This > _seems_ to say that any machine on the LAN, regardless of > permissions to mount, could possibly exploit any problems that > this message may be hinting to. > > How-To-Repeat > > From my experience and a quick look over other emails on this >topic, all you need is a FreeBSD 3.x machine running mountd(8), then >bring another machine on the network down (there may be ways to >generate the error by doing something less extreme than shutting down >a second machine, but this is when I observe the messages without >fail). > > Fix > > Origin of problem not yet understood. > > > Audit-Trail > >From: Martin Blapp <mb@imp.ch> >To: freebsd-gnats-submit@freebsd.org, > cjc@cc942873-a.ewndsr1.nj.home.com >Cc: >Subject: Re: bin/14709: umountall requests possibly mishandled by mountd(8) >Date: Fri, 05 Nov 1999 00:12:53 +0100 > > I've seen this several times on different machines. > Something seems to be very wrong here. I'll look into > this more close because I'm currently do a cleanup > of mountd. > > Thank you for your report > > Martin Blapp > Improware AG, Switzerland > > > >From: Vallo Kallaste <vallo@matti.ee> >To: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> >Cc: FreeBSD-gnats-submit@FreeBSD.ORG >Subject: Re: bin/14709: umountall requests possibly mishandled by mountd(8) >Date: Fri, 5 Nov 1999 07:53:27 +0200 > > On Thu, Nov 04, 1999 at 12:42:38PM -0500, "Crist J. Clark" <cjc@cc942873-a.ewn >dsr1.nj.home.com> wrote: > > > > > >Number: 14709 > > >Category: bin > > >Synopsis: umountall requests possibly mishandled by mountd(8) > > >Confidential: no > > >Severity: serious > > >Priority: medium > > >Responsible: freebsd-bugs > > >State: open > > >Quarter: > > >Keywords: > > >Date-Required: > > >Class: sw-bug > > >Submitter-Id: current-users > > >Arrival-Date: Thu Nov 4 09:50:00 PST 1999 > > >Closed-Date: > > >Last-Modified: > > >Originator: Crist J. Clark > > >Release: FreeBSD 3.3-STABLE i386 > > >Organization: > > >Environment: > > > > FreeBSD 3.x system with mountd(8) running. > > > > >Description: > > > > Several users have reported (search the -questions mail > > archive on the string 'umountall' for a sample) strange messages of > > the form, > > > > mountd[<pid>]: umountall request from <IP> from unprivileged port > > > > Where <IP> is an IP address of the host (not the loopback, however) > > appearing in their messages log. No events taking place on the server > > in question seems to correlate the the messages. > > > > I have been able to build a very strong correlation between > > the messages and other computers on the local network being shutdown > > (see the mail archives, > > > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=1737357+1744288+/usr/local/www/db/text/1999/freebsd-questions/19991017.freebsd-questions > > > > for some examples from my personal logs). > > I've seen such behavior with -current systems as well. Here's what I > have seen: > > Oct 5 22:07:11 myhakas mountd[150]: umountall request from 194.126.114.87 from unprivileged port > Oct 8 20:07:38 myhakas mountd[149]: umountall request from 194.126.114.87 from unprivileged port > Oct 8 21:34:30 myhakas mountd[149]: umountall request from 194.126.114.87 from unprivileged port > Oct 8 23:24:50 myhakas mountd[149]: umountall request from 194.126.114.87 from unprivileged port > Nov 2 20:02:32 myhakas mountd[150]: umountall request from 194.126.114.87 from unprivileged port > Nov 3 09:00:48 myhakas mountd[150]: umountall request from 194.126.114.87 from unprivileged port > > The NFS server machine is running -current and serves 3.3-STABLE and one > Solaris 2.6 box. > -- > > Vallo Kallaste > vallo@matti.ee > > >From: Martin Blapp <blapp@attic.ch> >To: freebsd-gnats-submit@freebsd.org, > cjc@cc942873-a.ewndsr1.nj.home.com >Cc: >Subject: Re: bin/14709: umountall requests possibly mishandled by mountd(8) >Date: Sat, 06 Nov 1999 12:57:40 +0000 > > From RFC 1813 : > --------------- > > 5.2.4 Procedure 4: UMNTALL - Remove all mount entries > > SYNOPSIS > > void MOUNTPROC3_UMNTALL(void) = 4; > > DESCRIPTION > > Procedure UMNTALL removes all of the mount entries for > this client previously recorded by calls to MNT. AUTH_UNIX > authentication or better is required. > > IMPLEMENTATION > > This procedure should be used by clients when they are > recovering after a system shutdown. If the client could > not successfully unmount all of its file systems before > being shutdown or the client crashed because of a software > or hardware problem, there may be servers which still have > mount entries for this client. This is an easy way for the > client to inform all servers at once that it does not have > any mounted file systems. However, since this procedure > is generally implemented using broadcast RPC, it is only > of limited usefullness. > > ERRORS > > There are no MOUNT protocol errors which can be returned > from this procedure. However, RPC errors may be returned > for authentication or other RPC failures. > > ---------------------------------------------------------------- > > Imagine we have three hosts in our little network: > > A: big server, has nfs-server running. > B: little server, has nfs-client and a nfs-server running. > C: workstation, has only nfs-clients. > > One can make the following conclusions: > > 1. If 'B' has mounted some filesystems from 'A', and 'B' > is being rebooted, mountd(8) from 'B' sends a broadcast > RPC_UMNTALL. The mountd(8) from 'A' should recieve it > and should remove all entries of host 'B' from > /var/db/mountdtab. It seems that our implementation of > rpc.mountd sends the RPC_UMNTALL on a unprivileged > port. If mountd(8) on 'A' is started with '-n', > the RPC_UMNTALL is successful. I'll have to look at > this today. > > 2. Running a NFS-Client does not mean we have a running NFS- > Server on the host. This is the setup for most workstations. > If we shutdown 'C', 'B' doesn't get informed and can not clean > it's /var/db/mountdtab. > > 3. As stated in the RFC, use of broadcast RPC is only of > limited usefullness. > > 4. The _only_ place where a RPC_UMNTALL call does make any sense > is _after_ reboot, but _before_ any new nfs-mounts. > > ---------------------------------------------------------------- > > I propose the following changes to *BSD* : > ------------------------------------------ > > 1. To have two mounttabs in /var/db/: > > /var/db/mountdtab (only for mountd) > /var/db/mounttab (for mount_nfs(8), umount(8)) > > In /var/db/mounttab we record all mounted > nfs-mounts, and if we unmount them, we remove > the entrys. > > 2. Add a command which calls RPC_UMNTALL for all entrys > in /var/db/mounttab during startup before any NFS-mount. > Remember: all remaining entries in /var/db/mounttab are > 'not properly unmounted nfs-mounts'. > > 3. Do not use broadcast RPC anymore, so we can have a time- > out control. We can also use a function like pingnfsserver() > from mount_nfs(8). > > 4. the following patch to mountd(8) > > Index: src/sbin/mountd/mountd.c > =================================================================== > RCS file: /usr/home/ncvs/src/sbin/mountd/mountd.c,v > retrieving revision 1.37 > diff -u -r1.37 mountd.c > --- mountd.c 1999/10/06 18:20:44 1.37 > +++ mountd.c 1999/11/06 11:59:55 > @@ -193,8 +193,6 @@ > void parsecred __P((char *, struct ucred *)); > int put_exlist __P((struct dirlist *, XDR *, struct dirlist *, int > *)); > int scan_tree __P((struct dirlist *, u_int32_t)); > -void send_umntall __P((void)); > -int umntall_each __P((caddr_t, struct sockaddr_in *)); > static void usage __P((void)); > int xdr_dir __P((XDR *, char *)); > int xdr_explist __P((XDR *, caddr_t)); > @@ -313,7 +311,6 @@ > signal(SIGQUIT, SIG_IGN); > } > signal(SIGHUP, (void (*) __P((int))) get_exportlist); > - signal(SIGTERM, (void (*) __P((int))) send_umntall); > { FILE *pidfile = fopen(_PATH_MOUNTDPID, "w"); > if (pidfile != NULL) { > fprintf(pidfile, "%d\n", getpid()); > @@ -2081,26 +2078,6 @@ > } > fprintf(mlfile, "%s %s\n", mlp->ml_host, mlp->ml_dirp); > fclose(mlfile); > -} > - > -/* > - * This function is called via. SIGTERM when the system is going down. > - * It sends a broadcast RPCMNT_UMNTALL. > - */ > -void > -send_umntall() > -{ > - (void) clnt_broadcast(RPCPROG_MNT, RPCMNT_VER1, RPCMNT_UMNTALL, > - xdr_void, (caddr_t)0, xdr_void, (caddr_t)0, > umntall_each); > - exit(0); > -} > - > -int > -umntall_each(resultsp, raddr) > - caddr_t resultsp; > - struct sockaddr_in *raddr; > -{ > - return (1); > } > > /* > > This would solve all the strange error-messages we have seen from > mountd(8) and leads also to proper handling of /var/db/mountdtab. > > Martin Blapp > Improware AG, Pratteln, Switzerland > > >From: Martin Blapp <mb@imp.ch> >To: freebsd-gnats-submit@freebsd.org, > cjc@cc942873-a.ewndsr1.nj.home.com >Cc: >Subject: Re: bin/14709: umountall requests possibly mishandled by mountd(8) >Date: Tue, 09 Nov 1999 20:47:21 +0100 > > Hello, > > These are the patches and a new command which should do exactly > what RFC 1813 proposes: > > http://www.attic.ch/patches/cleanmount/ > > Please test them and report any problems to me. If you find a better > name for cleanmount(8) I would be happy. > > Martin Blapp > Improware AG, Pratteln, Switzerland > > >State-Changed-From-To: open->closed >State-Changed-By: green >State-Changed-When: Sat Dec 18 15:39:03 PST 1999 >State-Changed-Why: >This has been fixed in -CURRENT and 3.3/3.4. Not so fast. Jan 5 18:59:43 backmail mountd[144]: umountall request from 192.168.229.3 from unprivileged port Jan 7 08:22:00 backmail mountd[144]: umountall request from 192.168.229.3 from unprivileged port Jan 7 09:18:25 backmail mountd[144]: umountall request from 192.168.229.3 from unprivileged port It still is griping about umountall requests coming from itself. # uname -a FreeBSD backmail.mydom.org 3.4-STABLE FreeBSD 3.4-STABLE #0: Tue Dec 21 14:23:45 EST 1999 postman@backmail.mydom.org:/u1/FreeBSD-3S/src/sys/compile/BACKMAIL i386 -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001071650.IAA95996>