Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!seismo!hao!hplabs!sri-unix!MCLINDEN@RUTGERS.ARPA
From: MCLINDEN@RUTGERS.ARPA
Newsgroups: net.unix-wizards
Subject: Re: chroot()
Message-ID: <2851@sri-arpa.UUCP>
Date: Wed, 13-Jul-83 00:09:02 EDT
Article-I.D.: sri-arpa.2851
Posted: Wed Jul 13 00:09:02 1983
Date-Received: Mon, 11-Jul-83 00:29:18 EDT
Lines: 29

From:  Sean McLinden 



  If there was ever a better reason for keeping this discussion public than 
  the current discussion, I don't know what it is.

  Bob English brings up a good point which shouldn't be dismissed,
  however, the solution may not be quite as complex as he stated. I am
  willing to admit that there are some difficulties with the example
  I gave IF one uses the Bourne shell. I specifically used the C-shell
  because it explicitly handles the cases of "/", "./", and ".." . I
  still maintain that if the shell that I listed (the C-shell) is called
  from a process which invokes chroot(), you can create a secure shell
  UNLESS you allow users to call programs within that heirarchy which are
  linked to programs outside that heirarchy. Furthermore, simple attempts
  such as writing a program which calls "chdir" won't work, even if you are
  the super user. Of course, I don't expect that users of the restricted
  shell will be able to do everything a non-restricted user can. But
  then I was speaking on the case of the casual user, such as student
  running Lisp or (God forbid), FORTRAN, who doesn't need to use programs
  which setuid 0 or  read kmem. I'd be the first to admit you can't have
  your cake and eat it too. And besides,  I wanted to talk about something
  besides passwords.

  [Bring on the lions!]

  Sean
-------