UUCP failures in att universe (LONG)

[Carl S. Gutekunst]

In article <2374 at ncr-sd.SanDiego.NCR.COM> Greg Noel writes:
>I reported this bug almost a year and a half ago the problem was given
>SPR#3560.  I have inquired about the status of the fix several times since
>then to no avail.

In article <1128 at bellboy.UUCP> hack at bellboy.UUCP (Greg Hackney) writes:
>That's real sad, cause having worked with the HDB source code, I figure
>it would take a programmer about 30 seconds to fix expfile.c.

C'mon guys, cut me a break, will ya? You know what we do to customers that
gripe too much: we hire them. Into R&D. Your first day on the job, you get to
fix your own SPRs. We call it "poetic justice." :-)

In all seriousness, this wasn't the easiest bug in the world to reproduce. No,
it doesn't happen all the time. And the bug wasn't *in* expfile.c, so making
30 second fixes there would not have accomplished much.

The bug is in the att mkdir(1) utility, which is execl'd in function mkdirs2()
to create the directories. System V hackers are painfully familiar with this;
not only do you have to exec(2) a utility to create directories, but mkdir(1)
is an suid program. As a consequence, mkdir(1) creates the directory with the
ownership of the *real* UID. This means that other suid programs (like uucico)
have to play nasty games with setuid(2), otherwise they won't be able to write
in the directory they just created. Netnews has a similar headache. 

The sequence of events in expfile.c mkdirs2() is:

	create the directory, via execl("/bin/mkdir", "mkdir", filename, 0)
	seteuid (Real Uid)
	chmod the directory to 777
	chown the directory to UUCP, that is, give the file away to UUCP
	seteuid (UUCP)

So far, so good. This works just fine on a 3B2; also works on OSx 4.0, which
is where we did our initial shakedown testing of BNU uucp.

In OSx 4.1, att mkdir(1) was modified to use the new SVR3 mkdir(2) call, in-
stead of the old mknod(2) technique. This was necessary for a lot of reasons,
not the least of which is that NFS won't let you use mknod(2) to create direc-
tories. 

The bug was that mkdir(1) was modified by simply replacing the mknod(2) code
with a call to mkdir(2), and removing the program's suid permissions. This
changed the utility's behavior: att mkdir(1) now created directories owned by
the *effective* UID, not the *real* UID. And HDB mkdirs2() blew up when it
tried to chmod(2) a file that it unexpectedly already owned.

The fix is a new version of att mkdir(1); specifically, the real SVR3.1 mkdir
utility instead of the hacked up one that was done to placate NFS. (The SVR3.1
code is actually quite interesting -- it is about double the size it neads to
be, simply to emulate the behavior of the old mkdir(1)). I have notified the
utilities group of this problem, and will put them together with RTOC so that
you both get a new att mkdir as soon as possible. No changes to BNU are needed.

Of course, I could modify expfile.c to use the mkdir(2) call instead of the
execl("/bin/mkdir"), but generally I prefer to leave source code as AT&T ships
it. It makes the code easier to maintain, and helps to avoid introducing new
bugs. And mkdir(1) needs to be fixed anyway. 

My humble apologies to Greg for taking so long on this one. And much groveling
and wimpering to my boss, who will want to know why I wasn't working on X.25
today. :-)

Happy now? Humiliate me into fixing a bug, will you? Jeez-o-peet all these
customers are such a damned nuisance. (And yes, my first day on the job, my
new boss handed me a stack of my own SPRs. At least one I promptly closed as
"user brain damage." :-)) 

<csg>