Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!pyramid!csg
From: csg@pyramid.UUCP (Carl S. Gutekunst)
Newsgroups: comp.unix.questions
Subject: Re: uucp {bugs,features}
Message-ID: <1440@pyramid.UUCP>
Date: Wed, 21-Jan-87 03:22:39 EST
Article-I.D.: pyramid.1440
Posted: Wed Jan 21 03:22:39 1987
Date-Received: Wed, 21-Jan-87 22:13:38 EST
References: <3700001@hpfcph.HP.COM>
Reply-To: csg@pyramid.UUCP (Carl S. Gutekunst)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 49

In article <3700001@hpfcph.HP.COM> Dale McCluskey asks some good questions:

>If it matters, I am using HP-UX (System V with added stuff) on an HP 9000.

It matters. That means you are using either stock System V or SVR2 UUCP.

>	1.  Why do files that are to be sent by uucp have to have read
>	access by "other", even if they are owned by uucp?

It could be argued that uucp(1) is excessively paranoid about permissions, but
it's really just lazy. Remember that UUCP is largely a batch-type operation.
The deamon that executes the copy will probably run under a different UID than
the user who made the request. These and other cases lead to many situations
where UUCP cannot read the file unless it has at least 444 permissions.

Rather than checking for all the possible conditions, uucp(1) simply assumes
that if "read other" is permitted, then the daemons will be guaranteed access
to the file no matter what. Of course, this supposedly helpful check does not
detect whether the daemon has execute permission on the directory tree. It
also means that many copies that do not really need "read other" are refused.

HoneyDanBer does the checks the right way, so "read other" is insisted upon
only when it's actually needed.

>	2.  Why does uucp create files with mode 666, regardless of their
>	mode on the original machine?

Actually, execute modes *are* preserved, but you are correct that read and
write modes are not. Since UUCP will be the owner of the copy, 666 modes are
deemed necessary for anyone other than UUCP to be able to read and write the
file. Making UUCP get the ownership correct would require a massive overhaul
of the code.

>	3.  Why does uucp refuse to forward files to non-public directories?
>	Here's the picture:
>	
>		A <---> B <---> C

Look in the uucp(1) man page. This is an arbitrary restriction of SVR2 uucp.
It simply will not let you send a file more than one hop away (AT&T calls this
"forwarding") to any directory other than uucppublic. I have been unable to
fathom why this restriction is imposed, although it's wired into the UUCP JCL
file format so I suppose it's too late to change now.

Note forwarding won't work at all unless all machines on the chain are running
the same flavor of UUCP. SVR2, Berkeley, and HoneyDanBer each use different
and incompatible techniques. (Yes, I know, in BSD you have to use uusend(1).)

<csg>