Messages in this thread |  | | From | Jonathan Larmour <> | Subject | Glitch in sys_chroot() | Date | 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.
|  |