[PATCH] Bug in do_mount()

do_mount() can sometimes fail to mount a filesystem, but still increment the filesystem module count. This patch against 2.4.2 should fix the problem. Jörgen --- fs/super.c.orig Sun Mar 11 20:25:26 2001 +++ fs/super.c Sun Mar 11 20:05:27 2001 @@ -1414,6 +1414,8 @@ fail: if

Re: [PATCH] Bug in do_mount()

> > if (list_empty(&sb->s_mounts)) > > kill_super(sb, 0); > > + else > > + put_filesystem(fstype); > > goto unlock_out; > Reference acquired by get_fs_type() is > released by put_filesystem() (near fs_out), _NOT_ by kill_super(). Yes. > kill_super() re

[PATCH] User chroot

Hi, Have you ever wondered why normal users are not allowed to chroot? I have. The reasons I can figure out are: * Changing root makes it trivial to trick suid/sgid binaries to do nasty things. * If root calls chroot and changes uid, he expects that the process can not escape to the old r

Re: [PATCH] User chroot

[EMAIL PROTECTED] ("H. Peter Anvin") writes: > Followup to: <20010627014534.B2654@ondska> > By author:Jorgen Cederlof <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > If we only allow user chroots for processes that have never been > >

Re: [PATCH] User chroot

On Wed, Jun 27, 2001 at 11:14:13 -0700, "H. Peter Anvin" wrote: > > > If we only allow user chroots for processes that have never been > > > chrooted before, and if the suid/sgid bits won't have any effect under > > > the new root, it should be perfectly safe to allow any user to chroot. > > > >