Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!caip!dayton!rosevax!aob!jim
From: jim@aob.uucp (Jim Anderson)
Newsgroups: net.unix-wizards
Subject: Re: chroot(2) security
Message-ID: <55@aob.uucp>
Date: Thu, 2-Oct-86 17:54:47 EDT
Article-I.D.: aob.55
Posted: Thu Oct  2 17:54:47 1986
Date-Received: Wed, 8-Oct-86 07:47:27 EDT
References: <158@itcatl.UUCP> <113@nonvon.UUCP> <15879@ucbvax.BERKELEY.EDU>
Reply-To: jim@aob.UUCP (Jim Anderson)
Organization: Anderson O'Brien, Inc.
Lines: 26

In article <15879@ucbvax.BERKELEY.EDU> ballou@brahms.UUCP (Kenneth R. Ballou) writes:
>In article <113@nonvon.UUCP> apn@nonvon.UUCP (apn) writes:
>>In article <158@itcatl.UUCP>, parris@itcatl.UUCP (Parris Hughes) writes:
>>> Could some wizard out there please clue me in as to why the chroot(2) call
>>> is only available to the super-user? 
>>> 
>>		... chroot to 
>>	/mnt23/user/test
>>	and then procedes to exec /bin/login
>
>Wait a minute, now it's *my* turn to be missing something here.  *Which*
>/bin/login?  If the root directory is now actually /mnt23/user/test, then
>presumably we would be trying to execute /mnt23/user/test/bin/login, not
>the /bin/login that is setuid root and which is able to log a user in.

But you could start by doing a link from /bin/login to
/mnt23/user/test/bin/login.  Then, even though you don't have any special
permissions with respect to your linked bin/login, you can still execute
it from your login directory.
When you are done, and you want to get rid of the /bin/login in your
directory, rm will probably mention that you don't have write permission
on a file that you don't own, but since you do have write permission on
your bin directory, it will let you remove the file (ie you CAN still
clean up your trail).

	Jim Anderson