Re: [patch 0/8] unprivileged mount syscall

Serge E. Hallyn
2007-04-09T20:55:10Z

Quoting Miklos Szeredi (miklos@szeredi.hu):
> > > One thing that is missing from this series is the ability to restrict
> > > user mounts to private namespaces. The reason is that private
> > > namespaces have still not gained the momentum and support needed for
> > > painless user experience. So such a feature would not yet get enough
> > > attention and testing. However adding such an optional restriction
> > > can be done with minimal changes in the future, once private
> > > namespaces have matured.
> >
> > What is the main reason for that feature? Would it be to prevent things
> > like login from being tricked by user mounts? Isn't it sufficient, in
> > fact, better, to require that the target of the mount be owned by the
> > user doing the mount?
>
> It's been discussed later in that thread. Basically you can fool a

I see now, sorry.

> lot of system programs (like backup) with mounting/binding in the
> global namespace. Restricting the destination doesn't always help.
>
> Miklos

It would be nice in general if we could avoid any sort of checks for
(mnt->mnt_ns == init_nsproxy.mnt_ns). Maybe that won't be possible,
but, taking the two listed examples:

1. mount --bind / ~/bindns; (later) userdel hallyn

I assume userdel does a simple stupid rm -rf without first umounting,
then? So (1) it seems wise to have userdel umount anything under ~user
first anyway, and (2) if $USER does a mount --bind from a source he
doesn't own, should we make the resulting mount read-only? (realizing
the read-only bind mount patches are still under development :) Or is
that overly restrictive somehow for fuse?

2. backups

Is this just a 'he's going to fill up the whole disk' issue? Frankly,
it seems wise to have cron or whatever is spawning the backup start in
it's own namespace right at boot. Generally when I think back on sites
where I've dealt with backup, backups were done on a separate server
which didn't allow userlogins anyway, so it wouldn't be a problem. But
I'm sure that's a limited (==erroneous) POV.

I do realize that the whole problem about corner cases isn't addressing
two little ones, but the fact that there are more we haven't thought of.
So are there any currently known use cases where requiring a CLONE_NEWNS
before user mounts is unacceptable?

thanks,
-serge