Conference noted::hackers_v1

    This reminds me of an old TECO macro that printed out the alphabet. The
    trick to the macro was that no character in the macro itself was
    repeated....
    
    tom_p

	    Have you tried this?

 		$ foo @SYS$SYDEVICE:[DECNET]DASTARDLY_FILE

			<_Jym_>

	    Have you tried this?

		$ foo :any nasty command you want

			<_Jym_>

    I experimented, without success with the
    
    		$ foo @something
    
    strategy.
    
    I appears that the "foo" symbol was originally defined as
    
    		$ foo == "$filespec"
    
    and that DCL doesn't execute the "@" on such a thing.  Instead,
    it merely runs the filespec and feeds the line "@something" to it.
    
    The ":" idea sounds promising, I'll let you know when I get results.
    
    /Eric
    
    p.s.	Has anyone figured out yet what system I'm hacking ??
    

    Yup.  You shouldn't pick on poor Mr. * with your hacking, with the
    service he's providing..
    
    -Mike

	    Yeah, leave E_ (____::|_____::) _e___e_____ alone!
			<_Jym_>

    Actually, I've been helping him.  When I first found loopholes in
    his system, I told him about it by coercing his software to send
    him a message telling him what the hole was.
    
    Anyway, it looks like ":" isn't a loophole either.  I'm not sure
    why not.  I suspect the filter avoids executing
    
    	$ foo . . .
    
    if the first character after "foo" isn't alphabetic.
    
    It's too bad the filter has to check for specific things.
    
    As a meta question, is there a more elegant way to protect
    one's software than the current method of specifically checking
    for certain known-to-be-nasty ascii characters ?
    
    /Eric

    
    The best way to trap 'nasty' commands is to only execute specified
    commands within the command procedure. For example never do anything
    like :-
    $'Command
    Always do something like :-
    $If "''Command'".eqs."FOO" Then $Foo
    (Make sure FOO is defined within the command procedure as a local
    	symbol, and that the user has no chance to re-define it. To
    	play REALLY safe you can re-define the command FOO every time
    	just before invoking it)
    To pass parameters to a command use F$PARSE on the file names. For
    example (parameter P1 is a file name) :-
    $P1 = F$Parse(P1)
    $If P1.eqs."" Then $Goto ....
    $Command 'P1
                
    You can always give the user a menu of numbered commands and force
    	him to use a numbered command instead.
    
    

    re .9:
    If you want a 'secure' .com file, never use the "''command'"
    construction.  See the note earlier about 'in-use' procedures.
    
    Scott

    If you want a secure command file, convert it to an executable image
    (using TPU, your favorite compiler, and the linker) and install it.
    
    	Jon 

    Umm, maybe I'm just being dense here, but I missed something.  What
    is the point of having a system remotely execute something you send
    it?  What can you do remotely that you can't do easier locally?
    Examples would be greatly appreciated...
    
    WPNS
    

	    Look for goodies that aren't on your system, for starters.
			<_Jym_>

Another thing you may want is to look at the batch or print queues
on the remote system, to see how your PRINT/REMOTE job is humming.

/Eric

    Or compile a long bliss job when your local node is 730 and the
    remote node is an 8800.:-)
    
    
    
    

    How about shutting down the network?
    
    T

We have some third-party software that is only licensed for use on
a specific cpu.  We have people who want to use this software who
are located on a different cpu.  The easiest solution seems to be
to copy the files back and forth as needed.

Martin.