[net.bugs.uucp] backslashes in uuxqt command cause lossage

warren@picuxa.UUCP (Warren Burstein) (08/21/86)

I discovered today that if you uux a command that contains one or
more backslashes, you get "execution permission denied" mail.  You
can see if your uuqxt has this problem by allowing execution of "sh"
and doing
     uux !"sh -c echo foo > /dev/ttyxx"
                    (plug in your tty, or another if handy, takes ~ 10 sec)

and then put a backslash in foo and see what happens.

This was observed on HDB running on a 3B2.

If anyone knows of a workaround, or if I am doing something dumb,
please let me know.
-- 

_  __  __
 |/  \/  \
 |___|___|/
 |
 | picuxa talks to ihnp4, cbosgd, bellcore and
 | nearly any other ATT/Bell site
/

wescott@sauron.UUCP (Mike Wescott) (08/26/86)

In article <156@picuxa.UUCP> warren@picuxa.UUCP (Warren Burstein) writes:
> I discovered today that if you uux a command that contains one or
> more backslashes, you get "execution permission denied" mail.

Yep. HDB uuxqt rejects commands with a backslash or a backquote.  Security
reasons.  I can see the reason for the backquote being excluded, but my
imagination has not found a fiendish way to use the backslash.  Not yet,
anyway.
-- 
	-Mike Wescott
	 ncrcae!wescott

csg@pyramid.UUCP (Carl S. Gutekunst) (08/27/86)

>> I discovered today that if you uux a command that contains one or
>> more backslashes, you get "execution permission denied" mail.
>
>Yep. HDB uuxqt rejects commands with a backslash or a backquote.

Ditto for 4.3BSD. The complete set of nasty characters (in ASCII order) is

	"&'(;<>\^`{|}

4.2BSD and SVR2.2 are the less strict; they allow the parentheses, backslash,
and braces.  Note that '(' is verboten, but ')' is not. Curious.

Of course, none of this is documented anywhere....

<csg>

greg@ncr-sd.UUCP (Greg Noel) (08/29/86)

HDB also doesn't handle quoted strings very well, either.  For example,
if you execute:
	uux -</some/input/file remotesite!lp "'-options'"
(because the options may have whitespace in them), what actually gets run is:
	lp ' -options '		<--- note the extra spaces inserted
Needless to say, this causes the remote command ("lp" in our example) some
confusion as it hunts for a file with a leading space in it instead of
evaluating the options and then reading the standard input.

If somebody has a fix for this, I'd dearly love to hear from you.......
-- 
-- Greg Noel, NCR Rancho Bernardo    Greg@ncr-sd.UUCP or Greg@nosc.ARPA