hack@bellboy.UUCP (Greg Hackney) (07/16/88)
There is a bug in the OSx 4.1 uucp programs on the att side of the Pyramid that causes occasional failures when trying to send files to it via uucp and uuto. Normally a file is received in a sub-directory of /usr/spool/uucppublic. The uucico program builds the sub-directorys. The program fails the first time the directory structure is built, but works on the 2nd try. So, a lot of times the 1st file has to be sent twice, i.e. uuto -p file1 tness7!mechjgh uuto -p file1 tness7!mechjgh uuto -p file2 tness7!mechjgh uuto -p file3 tness7!mechjgh uuto -p file4 tness7!mechjgh This was reported to Pyramid RTOC, who says it is a known bug and is on the list to be fixed. Soon I hope. -- Greg Hackney Southwestern Bell Telephone Co. Dallas, Texas root@tness7.UUCP
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (07/19/88)
In article <1124@bellboy.UUCP> hack@bellboy.UUCP (Greg Hackney) writes: >Normally a file is received in a sub-directory of /usr/spool/uucppublic. >The uucico program builds the sub-directorys [sic]. The program fails the >first time the directory structure is built, but works on the 2nd try. Actually, it suceeds on the first try, but for some reason, it thinks there was an error, so it rejects the file. Since the directory exists on the second transmission, the file transfer works. >This was reported to Pyramid RTOC, who says it is a known bug and is >on the list to be fixed. Soon I hope. I reported this bug almost a year and a half ago (I'm not sure of the exact date, but I sent them a a clarification of the problem, describing the exact symptoms given above, on April 17, 1987, so the original problem had to be sent to them before that); the problem was given SPR#3560. I have inquired about the status of the fix several times since then to no avail. I wouldn't hold your breath waiting for a cure. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
hack@bellboy.UUCP (Greg Hackney) (07/20/88)
In article <2374@ncr-sd.SanDiego.NCR.COM> greg@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. >-- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd 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. -- Greg
csg@pyramid.pyramid.com (Carl S. Gutekunst) (07/20/88)
In article <2374@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@bellboy.UUCP> hack@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>
hack@bellboy.UUCP (Greg Hackney) (07/22/88)
In article <31918@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >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." :-) Pyramid did well by hiring you Carl, cause you know your stuff. I would surely end up being your grunt.... >In all seriousness, this wasn't the easiest bug in the world >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. Thanks for the fix. >Happy now? Yes. > Humiliate me into fixing a bug, will you? Jeez-o-peet all these >customers are such a damned nuisance. That's why they call it "work" Carl. :-) It probably puts a Porsche in your garage... -- Greg
csg@pyramid.pyramid.com (Carl S. Gutekunst) (07/23/88)
In article <1130@bellboy.UUCP> hack@bellboy.UUCP (Greg Hackney) writes: >That's why they call it "work" Carl. :-) >It probably puts a Porsche in your garage... A *Porsche*??? Who do think I work for, Sun? :-) Would you believe a four-year-old Sentra station wagon? <csg>
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (07/27/88)
In article <2374@ncr-sd.SanDiego.NCR.COM> I wrote: >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@bellboy.UUCP> hack@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. In article <31918@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >C'mon guys, cut me a break, will ya? .... ... [ long explanation of bug removed ] ... >Happy now? Humiliate me into fixing a bug, will you? .... He sent me the bug fix, all right; it's a new version of /bin/mkdir. I installed it last Thursday to see if it would fix the problems. Son-of- a-gun, the directory botch problems went away; on top of that, the problem with the wrong ownership of the UUCP queue files also went away. So that much seems to work; congratulations, Carl; you managed to get it right. (I haven't yet found what you broke with your cure, but I'm still looking.) In his cover letter describing the bug fix to RTOC, he said: >Well, isn't this a fine kettle of fish: the SVR3.1 mkdir tickled a kernel bug >in setuid() that Greg Noel always suspected was there, but we couldn't repro- >duce. So.... to really do this right, you need a new mkdir, *and* a kernel PTF. (I hope he doesn't mind my quoting this; the information seems like it should be publicly available...) So, Carl (or somedody from RTOC, if they are following this), could you please send me this PTF? I'm reasonably happy with the current fix, so the PTF should be relative to OSx 4.4 instead of OSx 4.0 (which is what I'm running now). And while you're at it, could you give them a swift kick for me and tell then to ship me the bloody 4.4 tape? I \would/ like to upgrade.... In article <1130@bellboy.UUCP> hack@bellboy.UUCP (Greg Hackney) writes: >That's why they call it "work" Carl. :-) >It probably puts a Porsche in your garage... In article <32350@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >Would you believe a four-year-old Sentra station wagon? Hey, mine's a four-year-old Sentra as well, although I've got the sedan. Is this an instance of great minds thinking alike? (;-) -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd