Re: Glitch in sys_chroot()

Jonathan Larmour (JLarmour@origin-at.co.uk)
Fri, 15 Nov 1996 19:27:46 +0000


At 20:29 14/11/96 -0500, Elliot Lee wrote:
>On 14 Nov 1996, Aaron M. Ucko wrote:
>> Jonathan Larmour <jlarmour@origin-at.co.uk> writes:
>> That's because the bug is in chroot(8), not chroot(2). chroot(2) is
>> supposed to change only the root directory; Linux's behavior is
>> correct.
[snip]
>What makes Linux's behaviour correct in your opinion? If it is supposed to
>change the root directory, it should make sure the other parameters of the
>process follow that root directory, including PWD.

Indeed. In addition, the question is, what would it break?! What application
expects to be able to still be able to write into the directory after a
chroot? I think it should be fixed in either libc or the kernel, and I
believe the correct one should be the kernel, just in case.

There's maybe more of a question if the cwd was within the chroot'ed area,
e.g. cwd=/chroot/usr/bin and you do chroot /chroot fred. What I just
proposed changes to /, whereas maybe its more sensible to do some more
complex munging to work out that in this _particular_ case the cwd inode is
valid after all so don't touch it. The problem is, that to find this out we
need to get the pathname associated with the cwd inode. The absence of
directory hard links means it _should_ be unique, but there still isn't a
mechanism I know to do this.

Does anyone know of such a mechanism? If not, could someone in the right
place confirm the previous simple 2 line change will be added?

Ta,

Jonathan L.
Origin IT Services Ltd., 323 Cambridge Science Park, Cambridge, England.
Tel: +44 (1223) 423355 Fax: +44 (1223) 420724 E-mail: guess...
-------[ Do not think that every sad-eyed woman has loved and lost... ]------
-----------------------[ she may have got him. -Anon ]-----------------------
These opinions are all my own fault.