Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!munnari.oz.au!metro!ipso!runxtsa!brucee
From: brucee@runxtsa.runx.oz.au (Bruce Evans)
Newsgroups: comp.os.minix
Subject: Re: bug in chroot(2)?
Message-ID: <2101@runxtsa.runx.oz.au>
Date: 5 Aug 90 06:30:01 GMT
References: <441@alice.marco.UUCP>
Organization: RUNX Unix Timeshare.  Sydney, Australia.
Lines: 28

In article <441@alice.marco.UUCP> leo@marco.UUCP (Matthias Pfaller) writes:
>1. I could do a "cd /; cd .." and I was in the former root-directory
>   is this behaviour correct?

No. I think it will suffice to not follow the ".." link when the current
dicrectory is the root directory.

>2. [old binaries can still be executed]
>   I think the problem
>   is, that mm only changes to the exec'ing process workingdirectory, but
>   does not also change it's rootdirectory.

Yes. MM does a tell_fs(CHDIR, ...) to change the working directory.
do_chdir() in FS is kludged to switch from MM's workdir to the user's
workdir (and back) when called by MM. It also switches the effective uid,
but not the rootdir. I started to add code to switch to the user's rootdir
but stopped after realizing that this would zap the method of switching
back the workdir (by setting MM's workdir = MM's rootdir). But perhaps MM
doesn't need a workdir of its own.

The kludges are needed because MM is a server and the user task is not
visible to FS. Doing it "right" would require a lot of extra system calls
like special_open(user_nr, filename, mode), or overloading the bits in
the arguments as is already done for read() :-(.
-- 
Bruce Evans
Internet: brucee@runxtsa.runx.oz.au    UUCP: uunet!runxtsa.runx.oz.au!brucee
(My other address (evans@ditsyda.oz.au) no longer works)