question regarding UUCP and Suns

[Martin Boening]

Hello out there,

I have a question concerning uucp on sun workstations. The OS-Version the
Suns are allegedly running is Sun UNIX 4.2 Release 3.5. So here goes:

We have two suns standing side by side and connected via direct serial
line and want to test the implementation of a network service developed
here. One system is called dsmars, the other is called terra (Don't look
at me like that, I didn't name them :-)) We worked on system terra.  For
uucp-connections, this service calls a command fsend in the following
manner: (NB: everything in square brackets is variable and replaced in the
actual command by the correct data!)

uux - -x9 dsmars!fsend < /usr2/nerv/spool/[file]

This command is supposed to invoke fsend on the remote machine (dsmars)
and give the standard input to uux as standard input to fsend on the
remote machine. Because it's not quoted, '< /usr2/nerv/spool/[file]' is
supposed to redirect stdin for uux to [file]. On the local system the
files in question seem to be sent correctly and the local installation
happily closes the connection. On the system dsmars we get the LOGFILE
entry

  ... (logging info) ... XQT (DENIED)

which is startling because fsend appears in L.cmds, USERFILE allows access
to all directories and the access rights are as specified in the
installation guide.

This is USERFILE (the systems aren't connected to the outside world, so
it's safe to do this) on the machine designated as dsmars:

nuucp,dsmars /
, /

The first entry is in error of course, since dsmars won't log in on
itself, so for terra the second entry should be used for uucp as the first
match.

We thought, maybe we should quote the command proper, and issued:

uux - -x9 "dsmars!fsend" < /usr2/nerv/spool/[file]

but the result was the same.

The following command works fine on the remote machine using an option for
fsend (There are other reasons why this can't be used):

uux -x9 "dsmars!fsend -f !/usr2/nerv/spool/[file]"

which instructs fsend to take its input from the named file.

SO we tried a different command, which also appears in L.cmds, namely cat
as cat can also take standard input. (testfile stands for a full pathname
where every directory along the way as well as the file have mode 755)

First attempt: let uux shove its standard input to cat:

uux - -x9 "dsmars!cat - >dsmars!/usr/spool/uucppublic/test" < testfile

This time we got

 .... XQT DENIED (cat - )

Using

uux - -x9 "dsmars!cat dsmars!/usr/spool/uucppublic/test" < testfile

gave us the familiar "XQT (DENIED)" in the LOGFILE.  (But
/usr/spool/uucppublic is writable for everybody)

Second attempt: let cat on the remote machine get it's standard input from
testfile on the local system by itself:

Issuing

uux -x9 "dsmars!cat <!testfile > dsmars!/usr/spool/uucppublic"

yields 'XQT (DENIED)'.

Now give cat the file as in a normal call:

uux -x9 "dsmars!cat !testfile"

works fine on dsmars. As a matter of fact, any command in L.cmds works
fine as long as we don't use redirection of stdin/stdout.

It should be noted that in the tests with cat and fsend all files on the
local system were accessible. Also, all tests left the local system
happily transmitting the relevant data and execution files and then
closing the connection with "OK (conversation complete tty....)"

My question: has anybody encountered this problem? Does anybody see a
mistake that we don't in the commands we used?

Please answer via email to

mboen at nixpbe.UUCP

(other possible addresses:

USA:  uunet!linus!nixbur!nixpbe!mboening.pad
!USA: mcvax!unido!mboening.pad
)

BTW: The man-page for uux mentions that <,> and | should be quoted, ergo I
assume they can be used in command strings.

Thanks in advance

Martin Boening