From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: Remote backup h/w and the guest account
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 30 Sep 92 01:33:19 GMT

In <1992Sep28.160346.208@netnews.whoi.edu> scotty@eos-prog.whoi.edu (Scott J. McCue) writes:
|     We've got a 320S FileServer that has a couple (8mm and 9 track)
| of important tape drives on it. Various members of the staff will need
| access to them as they backup and restore their data. Because the
| machine is a fileserver, we have disallowed user accounts on it. The
| machine's filesystem is exported to other machines using NFS.
| 
|       SGI (and others, for all I know) has allowed remote access to
| devices with a command of form:
| 
|          tar xvf account@fileserver:/dev/tapedriver
| 
|      For this to happen, however, the user has to have an account on
| the fileserver and privileged status granted in the account's .rhosts
| file.
|       Another way to do it is to have a guest account on the fileserver
| that has no password and issue
| 
|          tar xvf machine:/dev/tapedriver
| 
| 
|   So, it appears that 3 choices are available to me...
| 
|      1. give all potential users of the tape drives accounts on the system,
|         despite wishing to have no user accounts on the system. I guess I
|         could make it less painful by making their login shell the restricted
|         shell (rsh).

Won't work.  with /bin/rsh, you can't run programs with a full pathname, and
/etc/rmt (the remote tape daemon) is definitely invoked with a full pathname.
(Try it.)

|      2. leave the password off of guest and worry about the security problems
|         afterward. Again, cut down on security problems by tagging the guest
|         account with rsh.

If you are on the internet, you almost certainly don't want to do this.
If not, or you are behind a firewall, it is probably the easiest thing
to implement.  See above as far as the /bin/rsh shell goes.

|      3. Give guest a password, and put all potential user hosts in the accounts 
|         .rhosts file. Note: the other machines are not especially secure as they
|         will have users other than those allowed access to the fileserver h/w.

If you are on the internet, and they aren't especially secure, you 
are probably going to have worse problems than this.  If you aren't
on the internet, you shouldn't have any 'security' problems from
having an open guest account, as long as you take a bit of care
with your system configuration on the server.  You could also
make your guest account be chroot'ed ala ftp, at the cost of
a fairly small directory tree with relatively few files in it,
and then have the login shell be a small, simple program that
does a chroot (you can't use the * in the shell field of the passwd
file, because the remote tape stuff requires a non-interactive
account).

|    Of the three, I prefer #2. I think that I'll have the fewest administrative and
|    security problems. Continually changing the status of the guest account password
|    is NOT an option.

Unfortunately, #2 won't work.

--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com