🚀 go-pugleaf

Tim et al,


> > This "problem" exists for ALL implementations of UUCP.  At least,
> > for all the ones I've seen (since V7), ....
>
> This does not appear to be the case.  My experience with 4.3 BSD UUCP has
> shown this not to be true, and my tests with 4.2 have shown there not to
> be a problem as well.  It seems to be limited to HDB (and possibly to the
> old System V version) of UUCP.

Hmm.. I just glanced into the 4.3-tahoe source we have on line here
and in chkpth.c:chkpth() was code which looked exactly as I expected.
Namely, it checks a string to see if its prefix is in the "path table"
which is read out of USERFILE.  It presumes that the string is a rooted
path name & fails if it doesn't begin with a '/' & fails if it doesn't have
a prefix in USERFILE.

> > >From a security standpoint it makes NO SENSE for AT&T to "fix" this
> > because it simply ain't broke.  It's up to us software wizards
> > to do UUCP mail right.
>
> I disagree with this.  Although it is important to check for permissions
> when doing file type activity, the HDB UUXQT is actually checking the argument
> list to rmail.  Please note that the assumption that I am making is that we
> should be able to transfer 822 compatible messages across a UUCP link.  If
> this is the case, the receiving UUCP site should handle legal 822.  For the
> type of security you are refering to, if required for mail, this capability
> should be built into rmail (it is the one that has to determine if the address
> is a file or an encoded O/R name).

No I still disagree.  Every version of UUCP I am familiar with (my familiarity
starts with V7..) has checked the arguments to remote command requests as
if they were file names.  `uuxqt' has no idea at all what sort of command
it is executing .. it only cares that it executes it and gathers up its
standard output & mails that back to the requestor.  Therefore it cannot
make the assumption that `rmail' is `safe' because everything on its command
line is e-mail addresses -- it simply does NOT know this!

Also note that X.400 addresses can contain all sorts of fun characters, some
of which will cause problems when passed through a /bin/sh command line.  This
is another little detail of doing commands via UUCP -- that commands are
executed via a shell.  One of the problems in doing RFC-822 this way is that
occasionally some vital quoting is lost.  This problem will be worse with X.400.

At any rate I can't fault UUCP for erring on the side of caution, even
if its slightly paranoid caution.  And yes you can

> Please note that the assumption that I am making is that we
> should be able to transfer 822 compatible messages across a UUCP link.

with the caveat that quoting will be stepped upon.  This is done thousands,
if not millions, of times a day in the UUCP portion of the matrix.

	David