Adam_E._Stein.HENR801c@xerox.com (09/30/88)
The syntax for mailing from Arpa Internet to Bitnet is:
u%h.bitnet@N where: u = user
h
= host
N
= machine (i.e. wiscvm.wisc.edu)
To go from Bitnet to Arpa Internet, the syntax is:
u@d.I where: u = user
d
= domain
I = com, edu, etc.
Hope that helps.
Adam Steinspam@IASTATE.EDU (Begley Michael L) (01/16/91)
Here's a question that a few people have answered "That's impossible".
It probably is, but it seems that *philosophically* it should be
possible...
What I'd like to do is execute a stream. The specific application I
have in mind is to compress all my executables, then execute them from
a simple shell script. Something like:
uncompress -c microemacs|execute /* uncompress microemacs.Z */
/* into a stream, and execute */
would automagically run a compressed copy of Microemacs. I know that
something like:
uncompress microemacs >temp /*uncompress microemacs.Z into
file temp */
temp /*run the uncompressed version */
rm temp /*and remove the file */
but that seems inelegant; kludgy, almost VMS-like!
I've been told that it can't be done because of swapping...
Can anyone help?
-mike begley
spam@iastate.edurbj@uunet.UU.NET (Root Boy Jim) (01/19/91)
In <1991Jan15.204849@IASTATE.EDU> spam@IASTATE.EDU (Begley Michael L) writes: >Here's a question that a few people have answered "That's impossible". I disagree. See below. >It probably is, but it seems that *philosophically* it should be possible... Maybe, but just because it's possible doesn't mean you should do it. >What I'd like to do is execute a stream. The specific application I >have in mind is to compress all my executables, then execute them from >a simple shell script. Something like: > > uncompress -c microemacs|execute /* uncompress microemacs.Z */ > /* into a stream, and execute */ > >would automagically run a compressed copy of Microemacs. I once suggested to Chris Torek that the kernel should execute compressed programs. He groaned. > I know that something like: > uncompress microemacs >temp /*uncompress into temp */ You mean zcat. > temp /*run the uncompressed version */ > rm temp /*and remove the file */ > >but that seems inelegant; kludgy, almost VMS-like! Harumph! What it is is LISP like. I once had three scripts called load, unload, and autoload, which went something like this: #! /bin/csh -f # load pathname set DIR=`dirname $1` set FILE=`basename $1` rm $1 mv $DIR/Z/$FILE.Z $1.Z exec uncompress $1 #! /bin/csh -f # unload pathname set DIR=`dirname $1` set FILE=`basename $1` mv $1 $DIR/Z ln -s $1 /usr/local/bin/autoload exec compress $DIR/Z/$1 #! /bin/csh -f # autoload a program and execute it # real programs are symlinked to autoload load $0 exec $0 $* Load & unload were suid. A tad insecure, but you could write wrappers. I am also typing this from memory; there were other features too. I unloaded most everything in /usr/bin. >I've been told that it can't be done because of swapping... Now if you wanted to do it online, you'd have to use a 407 (ld -N) file. You would do what all good boot programs do: copy the text and data to the right place, then jump to the start address. Royal pain. >Can anyone help? No. It's too hard to do right and so easy to do half assed. >-mike begley >spam@iastate.edu -- Root Boy Jim Cottrell <rbj@uunet.uu.net> Close the gap of the dark year in between
rat@aalps3.erg.sri.com (Ray Trent) (05/16/91)
Subject:Re: BSD tty security, part 3: How to Fix It Reply-To: rat@erg.sri.com (Ray Trent) Organization: SRI International, Menlo Park CA References: <etc.> <14021:May1521:56:2291@kramden.acf.nyu.edu> Date: Wed, 15 May 91 23:39:10 GMT In the referenced article, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Be serious. The whole point of a SECURE attention key is that it cannot >be violated by unprivileged applications (i.e., things outside the TCB). >And, as Bellovin told you, there's no need for an application to turn >off the SAK---you just make the SAK a variable-length signal if normal >data is fixed-length, and vice versa. This is a non-issue. This concept of a "secure" attention key is silly. If the terminal is sufficiently physically secure and you trust the users with access to it then no secure attention key is needed. If this isn't the case, no secure attention key is possible. It is almost as easy for me to plug in an 8 bit ascii fixed length character filter into the line as it is for me to set up a trojan horse password stealer in the first place. Even if I couldn't simply purchase such a toy, it would be trivial to make in my garage. All you've done is make the stealer's job slightly more difficult. No, amend that, you've also instilled an unwarranted confidence in the minds of your users. If you want to do this right, use a zero knowledge exchange to mutually verify the identity of both the login program and the user logging in. The easy, non-hardware ways to do this probably still won't protect against people looking over your shoulder, but they prevent the problems under discussion very nicely and much more securely. -- "When you're down, it's a long way up When you're up, it's a long way down It's all the same thing And it's no new tale to tell" ../ray\..