Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx): > > Sorry for the late response ... > > Serge E. Hallyn wrote: > >Trivial patch, and I'm not sure whether we want this or want to > >do it this way. But it saves me having to do it during my restart.sh > >wrapper shell-script. > > This looks useful. > > I wonder if it makes sense to generalize that to allow the user > to request any mount (and multiple mounts), e.g. > restart --mount="......" --mount="......." ... Or just a --fstab=some_file option? > With this switch, 'restart' will create a new mntns and do the > mounts in it. > > We can then add shortcuts, like --mount-ptys. > > However, I'm concerned about the security implications: ideally > 'restart' will be setuid executable, so it must be prudent in > accepting such generic requests as 'mount'. Hmm, we could use our own mount binary, which is willing to mount things like devpts and proc as root (since that's completely private) but otherwise runs the mounts as the original user? Eventually do that on top of Miklos' unprivileged-mounts patchset, which will allow bind mounts on top of dirs/files to which the user has write access. In the meantime other mounts would only be allowed if the user was originally root. So basically our mount binary would be run with euid=0 and ruid=suid=N where N is the original userid. > This last argument is also valid if we stay with this patch, > because it is racy (time of check to time of use). Yeah I'm not sure we can solve this right now. We might be best off saying that only ruid=0 can do the mounts, and mention something about setuid-root restart.c can trust TPM-signed checkpoint images. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
