sysvr3.2 & uucp failures

[Leslie Mikesell]

What can cause uucp to give a PERMISSION DENIED seemingly at random?
This problem started when I upgraded my 3B2 to SysVr3.2 (HDB uucp).
The PERMISSIONS file is fine and hasn't been changed in months, but
about 1 transmission out of 20 is failing.  

Here is what uulog says about it:
uucp chinet  (6/21-3:12:20,234,4) REMOTE REQUESTED (chinet!/tmp/snd3295 -->
     afbf01!~/receive/les/chinet/ (les))
uucp chinet  (6/21-3:12:21,234,4) PERMISSION (DENIED)

And this is the directory in question (note that is was touched at the
time of the transfer, but it is still empty).
drwxrwxrwx 2 uucp other 32 Jun 21 03:12 /usr/spool/uucppublic/receive/les/chinet

Other possibly related facts:
The receiving machine (afbf01) initiated the call.  No one was on the
machine at the time so it was almost certainly started by cron.  Some
mail transfers succeeded on the same call.  Transmissions to the same
directory succeeded the day before (also started by cron on afbf01).

My guess at what is happening:
Uudemon.cleanup may have deleted the directory /usr/spool/uucppublic/receive/
les/chinet, and uucico barfed when re-creating it.  SysVr3.2 /bin/sh has
a new security feature that forces a switch to the "real" uid if the effective
uid is different.  This might affect setuid programs that use system(mkdir...)
(although SysVr3.x has mkdir() anyway and the directory is being created
properly).  For example, you cannot log in as a normal user, "su", and make
a directory where the normal user could not, unless you "su - root". 
I think that the other failures have also been on the first call after
uudemon.cleanup would have run.  Perhaps it works again on the next call
because the directory exists again.
Does anyone have any better ideas?

This is especially annoying because I normally use "uuto -p" to transfer
compressed files and delete the originals.  Before the switch to 3.2 it
had never failed.

Les Mikesell