Re: hide the commabd executed from ps,who
Eric G Miller <egm2@jps.net> writes:
EGM> On Thu, May 18, 2000 at 12:57:18AM +0800, 50191914@uxmail.cityu.edu.hk wrote:
>> But for example,what if I want to write a shell script which will login
>> to the remote server automatically?e.g..for some cgi...etc...
EGM>
EGM> Couldn't you put the password in a variable? Would the real value show
EGM> up, or just the variable name?
EGM>
EGM> #! /bin/sh
EGM> MY_PASS=Xhef#&8wertyqP[,
EGM>
EGM> exec mysql [args] $MY_PASS
The real password would show up.
At some point, the kernel has to be able to run the program and hand
it all of its command-line arguments. The *shell* will expand
$MY_PASS, and try to run 'mysql arg1 arg2 password', which the kernel
will dutifully announce via the /proc interface.
None of the "run a program which runs a program with the password as a
command-line argument" schemes will work, because the subprogram will
have the password as a command-line argument. It's worth noting that
the environment is similarly insecure, since (BSD) ps's "e" switch
(not the SysV "-e" switch) will display programs' environments.
If what you're trying to do is be lazy and not give your password to
the mail server when you're incing your POP mail, this is probably a
Bad Idea (TM), and you probably really want to go ahead and type your
password. (Though there are other issues with this, most notably
those involving trust of the mail server and packet sniffers on the
network.)
OTOH, if this is for a server that needs to authenticate itself to
some other server, I'm not sure what a good answer is. Kerberos
certainly has a scheme for dealing with this (a machine has a
"srvtab", which is a file which essentially has a binary password so
that the machine can get a ticket-granting ticket for itself), but
Kerberos will probably be overkill for most applications. Having a
program-readable ssh private RSA key might be a better, more-or-less
equivalent solution; ssh is in wider use, requires less
infrastructure, and provides good encryption and authentication.
Creating the (remote) server might be a bit of a problem, since I
don't think there's a good way to tell whether a particular invocation
is over an encrypted ssh channel or not.
--
David Maze dmaze@mit.edu http://www.mit.edu/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
Reply to: