Very Computer

I work on a distributed application, and have been tasked with a feature
that lets users start all of our processes on a set of configured machines
from one 'master' box. The options I'm looking at now are rsh vs. inetd.
inetd gives greater control (rsh lets you run any command, while with inetd
I can ensure only my scripts are executed) at the cost of more complexity
(writing what is still a simple script kicked off by inetd instead of the
rsh one-liner, and handling authentication ourselves instead of relying on
the OS). inetd is more difficult to administrate, but not by much. So, if
customers wouldn't mind enabling/configuring rsh, I'd rather go that route,
because it's easier.

Not being an expert, I'm aware that there's many other issues regarding
starting distributed apps, but the main question I'm concerned about here
is: would a network-savvy customer object to our app using rsh?

[snip]

Quote:>Not being an expert, I'm aware that there's many other issues regarding
>starting distributed apps, but the main question I'm concerned about here
>is: would a network-savvy customer object to our app using rsh?

You should always ask yourself what the risks are. For example :

- is this limited to an Intranet environment, or could some commands
go through an Extranet (or worse, the Internet) ?
- what is the worst that could happen if someone intercepted the
login/password ? (they are sent in clear text)
Could the remote systems be used for something else than your
predefined set of applications ?
- what other resources might be exposed through these remote
systems, and how "confidential" is that information ?

I wouldn't recommend it unless the security issue really is of
no concern - for instance to look up a telephone number on a
local server (using a restricted shell), in an environment without
any confidential information.

Michel.

Quote:> You should always ask yourself what the risks are. For example :

> - is this limited to an Intranet environment, or could some commands
> go through an Extranet (or worse, the Internet) ?

Typically all the machines running our app are behind one firewall. It's
distributed more for load-balancing rather than handling hundreds of
internet clients. So as long as rsh's trusted users and hosts are set up
right, start/stop requests couldn't come from anywhere but inside the
cluster.

Quote:> - what is the worst that could happen if someone intercepted the
> login/password ? (they are sent in clear text)
> Could the remote systems be used for something else than your
> predefined set of applications ?
> - what other resources might be exposed through these remote
> systems, and how "confidential" is that information ?

These are questions that users have to answer themselves. Start/stop is kind
of a minor feature in our app, so the spin we could put on it is "You can
have the convenience of remote start/stop if you're willing to manage rsh.
Be advised though, of <insert your caveats here>". If users aren't willing,
they can rlogin to each machine and start it by hand. It's less convenient,
but they can sleep better.

Yes, I would object to using rsh.  In fact, I have RSA Security's Keon
Security Server installed on our Unix boxes to prevent users from using
rsh.

Nick