Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > "Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > > > Quoting Miklos Szeredi (miklos@xxxxxxxxxx): > >> On Thu, 11 Sep 2008, ebiederm@xxxxxxxxxxxx (Eric W. Biederman) > >> > There is a weird corner case I'm trying to wrap my head around. > >> > unlink and rmdir do not work on dentries that are mount points > >> > in another mount namespace. > >> > > >> > Which is at least needed for the moment so we don't leak mounts. > >> > > >> > Once we have unprivileged mounts does that introduce a DOS attack? > >> > >> Hmm, yes. That's a tough one... > >> > >> I think if the dentry has only user mounts, unlink should go ahead and > >> on success dissolve any mounts on the dentry. Does that sound > >> workable? > >> > >> Thanks, > >> Miklos > > > > Is it really a problem? The admin can always go ahead and kill the > > user, which already takes care of any mounts in private namespaces, > > which I think is Eric's primary concern. IT also takes care of that > > user's processes pinning files under the mounts. So now the admin can > > umount all the user's mounts in the init namespace (using a script > > parsing /proc/self/mountinfo if need be), and delete the files. > > > > Doesn't really seem like a problem. > > > > Or am I missing Eric's real concern? > > Assume /user is the base unprivileged mount point. > > echo dummy > /tmp/1234 > mount --bind /etc /user/etc > mount --bind /tmp/1234 /user/etc/passwd Ok, but this is all done as root. Kind of a silly thing for root to do :) So in order for me as an unprivileged user to pin a dentry by mounting over it, I have to have write permission to the dentry to begin with as well as the dentry being under a user=hallyn mount. > Now you can't create /etc/passwd.new and rename it to /etc/passwd. > Stopping adduser from working. > > As Miklos said this can apply to any file or any directory, so it can > be a DOS against any other user on the system. Except I need to own the mount as well as the dentry. So after root does mmount --bind -o user=hallyn /home/hallyn /home/hallyn mmount --bind -o user=hallyn /home/serge /home/serge if user serge (uid 501) tries to mmount --bind /etc /home/hallyn/etc mmount --bind /etc /home/serge/etc permission for the first will be denied because serge does not have write perms to /home/hallyn/etc, and permission for the second will be denied because only hallyn may mount under /home/serge. If root properly did mmount --bind -o user=hallyn /home/hallyn /home/hallyn mmount --bind -o user=serge /home/serge /home/serge and then hallyn does mmount --bind /etc /home/hallyn/etc and serge does mmount --bind /home/hallyn/etc /home/serge/etc then hallyn can still ummount /home/hallyn/etc. And we've decided that users cannot (for now) do shared mounts. So I'm still not sure where there is the potential for danger? > It is also contrary to classic unix and linux semantics as open files > don't otherwise prevent unlink, rename or, rmdir from happening. So > applications are not going to be ready for it. > > At a practical level I recently replace chroot with mount namespaces > to simplify handling of mounts and ouch! When a process goes crazy > and doesn't exit when you expect and then you try and delete the > directory it is a pain. > > Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
