From cjc@cc942873-a.ewndsr1.nj.home.com Thu Nov  4 09:40:04 1999
Return-Path: <cjc@cc942873-a.ewndsr1.nj.home.com>
Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207])
	by hub.freebsd.org (Postfix) with ESMTP id B6EDB14DED
	for <FreeBSD-gnats-submit@freebsd.org>; Thu,  4 Nov 1999 09:40:01 -0800 (PST)
	(envelope-from cjc@cc942873-a.ewndsr1.nj.home.com)
Received: (from cjc@localhost)
	by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id MAA20940;
	Thu, 4 Nov 1999 12:42:38 -0500 (EST)
	(envelope-from cjc)
Message-Id: <199911041742.MAA20940@cc942873-a.ewndsr1.nj.home.com>
Date: Thu, 4 Nov 1999 12:42:38 -0500 (EST)
From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com>
Reply-To: cjc@cc942873-a.ewndsr1.nj.home.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: umountall requests possibly mishandled by mountd(8)
X-Send-Pr-Version: 3.2

>Number:         14709
>Category:       bin
>Synopsis:       umountall requests possibly mishandled by mountd(8)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Nov  4 09:50:00 PST 1999
>Closed-Date:    Sat Dec 18 15:39:03 PST 1999
>Last-Modified:  Fri Jan  7 08:50:02 PST 2000
>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 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.


>Release-Note:
>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.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: 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. 

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
 
>Unformatted:
