From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: Grrrr fusermount. Date: Wed, 09 Oct 2013 16:35:56 -0700 Message-ID: <87ob6yyq3n.fsf@xmission.com> References: <87a9kkax0j.fsf@xmission.com> <8761v7h2pt.fsf@tw-ebiederman.twitter.com> <87li281wx6.fsf_-_@xmission.com> <874n8w1wsz.fsf_-_@xmission.com> <20131008155041.GI14242@tucsk.piliscsaba.szeredi.hu> <877gdne8pr.fsf@xmission.com> <8761t65kd2.fsf_-_@xmission.com> Mime-Version: 1.0 Content-Type: text/plain Cc: Miklos Szeredi , "Serge E. Hallyn" , Al Viro , Linux-Fsdevel , Kernel Mailing List , Rob Landley , Linus Torvalds To: Andy Lutomirski Return-path: In-Reply-To: (Andy Lutomirski's message of "Wed, 9 Oct 2013 13:09:17 -0700") Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Andy Lutomirski writes: > On Wed, Oct 9, 2013 at 12:12 PM, Eric W. Biederman > wrote: >> ebiederm@xmission.com (Eric W. Biederman) writes: >> >>> But I will go through and read the old fusermount code before I get too >>> much farther just so I understand what I am potentially breaking. >> >> Grr. >> >> So I have just read the fusermount umount code and the hack that it uses >> before there was UMOUNT_NOFOLLOW support in the vm. >> >> If I walk this path of lazy unmounts and detaching directories, anyone >> with a new kernel and an old copy of fusermount and a nfs mounted home >> directory will be able to exploit the fusermount umount symlink race. >> >> Unless we can declare that old fusermount binaries are buggy beyond >> supporting this patchset as it exists is dead. > > What's the hack that it does? The problem is that "umount -l /some/user/supplied/path" can unmount anything. Even after checking mtab etc there are races, and replacing "path" with a symlink will still allow you to unmount anything. So when not usering UMOUNT_NOFOLLOW fusermount will do: cd "/some/user/supplied/" clone(CLONE_NEWNS) mount --make-rprivate / COUNT=$(cat /proc/mounts | wc -l) mount --rbind . / Look at new /proc/mounts entries past $COUNT and see if there is an entry for "path" if $found exit 0 else exit 1 wait if ($? == 0) umount -l "path" As everything happens in the directory just below the mount point we are only concerned about things that happen in that directory. This does mean there is a window between checking that path is a valid fuse mount point and when that mountpoint is unmounted. So if someone can unlink/rename the mount point and replace it with a symlink during that small window it is possible to unmount anything. Today the d_mountpoint tests and the requirement distributed filesystems (aka nfs) lie to the vfs prevent those issues. The UMOUNT_NOFOLLOW code which appears in fuse 2.9.0 is new enough that distro's like CentOS6 don't ship it yet. Eric