SysVr3.2 uucp problem

[Leslie Mikesell]

Problem with HDB uucp on 3B2 & '386 AT&T SysVr3.2 unix.

I have been seeing more or less random "Permission Denied" messages when
using uuto to send files to a system running SysVr3.2, and finally found
the problem.
When uucico is started by root, it will refuse to create more than one
directory level to receive the file.  The "uuto" shell script sends files
to /usr/spool/uucpublic/receive/USER/FROM_MACHINE when the command:
uuto file(s) MACHINE!USER is given.  The uudemon.cleanup script removes
empty directories in /usr/spool/uucppublic periodically, so the transfer
is likely to require the creation of at least two directory levels. 

The following is an attempt to:       (from machine afbf01)
uucp testfile afbf14!/usr/spool/uucppublic/receive/les/afbf01/
  (directory /usr/spool/uucppublic/receive/ exists on afbf14)

The call is placed from afbf14, with root starting the uucico.
------- 
rmesg - '' got S /usr/les/testfile /usr/spool/uucppublic/receive/les/afbf01/
      les -dc D.0 644 les
 PROCESS: msg - S /usr/les/testfile /usr/spool/uucppublic/receive/les/afbf01/
      les -dc D.0 644 les
SNDFILE:
msg - S
Remote Requested: afbf01!/usr/les/testfile -->
       afbf14!/usr/spool/uucppublic/receive/les/afbf01/ (les)
SLAVE - filename: /usr/spool/uucppublic/receive/les/afbf01/
mkdir - /usr
mkdir - /usr/spool
mkdir - /usr/spool/uucppublic
mkdir - /usr/spool/uucppublic/receive
mkdir - /usr/spool/uucppublic/receive/les
mkdir - /usr/spool/uucppublic/receive/les/afbf01
CAN'T SETUID 0
wmesg 'S'N2
Failed: Access Denied
---------

The directory /usr/spool/uucppublic/receive/les/afbf01 is in fact created
with the proper modes and following the exact procedure again (while the
directories exist) will succeed.  It will also succeed if only one directory
must be created (in this case, if /usr/spool/uucppublic/receive/les/ exists).
This did not happen with SysVr3.1.  Was the change supposed to be a security
enhancement or a fix for some other bug?

Les Mikesell