Glitch in sys_chroot()

Jonathan Larmour (jlarmour@origin-at.co.uk)
14 Nov 1996 21:19:45 -0000


This was commented on in some security lists, but it never seems
to have made it into the kernel as of 2.0.25.

sys_chroot() doesn't change directory after the chroot has happened.

e.g., if you write a little app that just creates a file in the
current dir, and compile it statically. Then if you do e.g.
chroot /tmp myapp from somewhere other than /tmp, you will find
it will try and create it in your current directory, and not in
/tmp!

This poses all sorts of security problems due to the use of chroot
as a form of protection of apps, but if the apps haven't changed
directory this is not good at all! I know there are other issues
with chroot to aid security, but this seems more like a bug than
an issue.

The simple solution in fs/open.c is the addition of the following
to sys_chroot() before the return:

iput(current->fs->pwd);
current->fs->pwd = inode;
inode->i_count++;

Any problems? Could this be put in the 2.0.26 (if there will be
one) and 2.1.x please?

Jonathan L.

-- 
Origin UK, 323 Cambridge Science Park, Cambridge, England. CB4 4WG.
-------[ 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.