Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!hc!lll-winken!uunet!ateng!chip From: chip@ateng.ateng.com (Chip Salzenberg) Newsgroups: comp.unix.xenix Subject: Re: uucico problem (XCLUDE); also, 2.2 vs 2.3. Message-ID: <1989Apr6.123637.27750@ateng.ateng.com> Date: 6 Apr 89 16:36:37 GMT References: <715@vector.UUCP> <1989Mar18.233136.14960@ateng.ateng.com> <764@vector.UUCP> Organization: A T Engineering, Tampa, FL Lines: 37 According to chip@vector.UUCP (Chip Rosenthal): >chip@ateng.ateng.com (Chip Salzenberg) writes: >>Yup. The SVID exlicitly states that the XCLUDE flag remains in effect even >>when a devices is closed. [...] My reading of the SVID didn't give me any >>indication that a fixup was possible, even as root. > >One has to wonder if this area of SVID was rationally developed or if >it covers a kludge in the initial tty driver. Henry Spencer (?) jokes that SVID means System V Implementation Description. In the case of the XCLUDE kludge -- er, flag -- I entirely agree. >Are you saying: > > drwxrwx-wx 6 uucp uucp 4336 Mar 19 17:56 /usr/spool/uucp > >won't work? That's what I do now. It could eventually break unless you *never* run two simulaneous uucico's. The results could be that the directory is automagically changed to 777 again. There's a race condition in uucico. The sequence of events is: get old-modes of /usr/spool/uucp chmod 777 /usr/spool/uucp mkdir /usr/spool/uucp/systemname chmod old-modes /usr/spool/uucp This broken behavior is required because (1) the mkdir system call isn't used, since uucico was compiled with the Development System 2.2, and (2) System V's setuid behavior is *bizarre*, and it interacts oddly with the setuid bit on /bin/mkdir. *SIGH*. -- Chip Salzenberg or A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."