Path: utzoo!utgpu!water!watmath!clyde!att!mtunx!rutgers!cmcl2!brl-adm!husc6!bu-cs!budd
From: budd@bu-cs.BU.EDU (Philip Budne)
Newsgroups: comp.unix.wizards
Subject: Re: Doing the unexpected
Summary: user invoked inetd caused RPC havoc
Keywords: Sun RPC rc inetd unexpected havoc mountd portmap
Message-ID: <23231@bu-cs.BU.EDU>
Date: 9 Jun 88 02:08:54 GMT
References: <14650@brl-adm.ARPA> <May.28.09.25.58.1988.25810@topaz.rutgers.edu>
Reply-To: budd@buit2.bu.edu (Phil Budne)
Followup-To: comp.unix.wizards
Organization: Boston Univ.
Lines: 37

All this is from experience managing a SOS 3.4 cluster, I have no
knowledge of how things may have changed in 4.0.

One example of how a user running /etc/rc* files can cause mayhem is a
user starting a private copy of inetd.  The new inetd will try to bind
local sockets and fail for the ordinary tcp and udp based services,
but will re-register RPC based services with the portmapper.

This happened once here, and all rcp.mountd requests were being
serviced by and failing, returning EACCESS (presumably on an call to
open with the path of the mount (to get an fd to hand to getfh(2))

It took me QUITE a while to track this down after searching for and
finding no applicable references to EACCESS in the source for either
client or server nfs.

portmap and nfsd should be immune to this as they bind to reserved
sockets, but ypbind and ypserv may also have this weakness.

In short portmap does not provide rigorous defense of the ports it
names.  In fact any user can call pmap_unset;

/* rpcrm.c -- p budne@bu/dsg */
main( c, v )
	int c;
	char *v[];
{
	if( c != 3 ) {
		printf("%s prog version\n", v[0] );
		exit( 1 );
	} /* wrong number of args */

	if( pmap_unset( atoi( v[1] ), atoi( v[2] ) ) )
	    puts( "OK" );
	else
	    puts( "failed" );
} /* main */