Bug 14709
| Summary: | umountall requests possibly mishandled by mountd(8) | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Crist J. Clark <cjc> |
| Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 3.3-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Crist J. Clark
1999-11-04 17:50:00 UTC
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 On Thu, Nov 04, 1999 at 12:42:38PM -0500, "Crist J. Clark" <cjc@cc942873-a.ewndsr1.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 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
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 This has been fixed in -CURRENT and 3.3/3.4. [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 |
