serious bug in SunOS rpc.lockd with hostnames >= 20 chars

[Erik E. Fair]

In the referenced article, weon at ALADDIN.SOLVIT.CO.KR (Taehwan Weon) writes:

	I have configured my Solbourne machine, named aladdin.solvit.co.kr,
	as a primary name server.  Unfortunately, I found that NFS
	connection requests from client workstations denied by aladdin.
	I guess that the problem would be caused by the name server.

This may or may not be your problem; your description is not
sufficiently precise to tell.

There is an incredibly egregious bug in all the versions of rpc.lockd
that I was able to find and examine, including SunOS, UNICOS, Ultrix,
etc. Given this range, I would say that this bug is in the original
Sun NFS sources. The bug is that rpc.lockd doesn't use the MAXHOSTNAMELEN
definition from param.h when setting up the buffer for gethostname(2),
and does not use it as one of the arguments to gethostname(2), either.

They just define the buffer to be 20 characters long. Your host name is
precisely that long. The failure mode is that rpc.lockd can't find the
internet address from a truncated hostname, so rpc.lockd doesn't work,
and therefore, all lockf(2) system calls on files on the affected host
hang indefinitely. We found this the hard way.

The simple work around is to use the unqualified simple name of your
host for the {set,get}hostname(2) system calls, and spread around the
FQDN everywhere else that you need it (e.g. resolv.conf, sendmail.cf,
etc). Of course, if you have sources, you can make the trivial change
to rpc.lockd, recompile, and be happy. Unfortunately, most people don't
seem to have sources these days.

I also suggest that you call your OS software vendor (be they the
manufacturer of the hardware, or whatever), and let them know that
this kind of dumb coding practice is not acceptable.

	Erik E. Fair	apple!fair	fair at apple.com