Quoting Eric W. Biederman (ebiederm@xmission.com):
quoted text
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
> 
> 
> > Ok, but this is all done as root.  Kind of a silly thing for root to
> > do :)
> 
> There are less silly examples like setting up a chroot type
> environment contained in a mount namespace and having a kernel oops
> and then not being able to delete all of your files.

I wasn't saying that I believe I can win an argument by knocking down
one example :)

In fact I'm not trying to win an argument.  Because I'm quite sure you
and Miklos are right, and I just need to figure out what I'm missing.

quoted text
> > 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.
> 
> That second condition is interesting requiring write permission of the
> dentry.  I thought we had obviated the need for that when we added
> ownership to the mounts themselves.  In this case at least it shouldn't
> it be write permission on the directory containing the dentry.

Oh no, it seems I'm wrong, that's not a condition.  Just tested it.

quoted text
> >> 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?
> 
> Ok.  Let's pick on something a little more interesting.
> 
> root does:
> 	mmount --bind -o user=hallyn /home/hallyn /home/hallyn
> hallyn does:
> 	mount --bind /tmp /home/hallyn/tmp
>         touch dummy
> 	mount --bind dummy /home/hallyn/tmp/some_shared_file_I_have_write_access_to.
> 
> Which allows me to transform write permissions into the ability to
> deny someone else the ability to delete a file.

Yup, that's an interesting example.

Still an admin *can* work around that, if he can sufficiently parse
/proc/self/mountinfo to know to umount
/home/hallyn/tmp/some_shared_file_I_have_write_access_to.

Is that sufficient?  Probably not?

quoted text
> This seems to mess up things like revoke.

Hey, do we have revoke now?  :)

quoted text
> At a practical level it is a real annoyance, regardless of the security
> implications.
> 
> As a point of comparison plan9 does not have that restriction.

Why doesn't it have that restriction?  Does it always allow you to rm a
mounted-over file?

-serge
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/