uucico problem (XCLUDE); also, 2.2 vs 2.3.

[Chip Salzenberg]

According to chip at vector.UUCP (Chip Rosenthal):
>chip at 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             <chip at ateng.com> or <uunet!ateng!chip>
A T Engineering             Me?  Speak for my company?  Surely you jest!
	  "It's no good.  They're tapping the lines."