[lxc-users] from lxc to lxd but sharing dir hell

[Serge E. Hallyn]

Quoting Ivan Ogai (lxc-users at ogai.name):
> * Serge E. Hallyn <serge at hallyn.com> [2016-09-13 15:48]:
> > On Tue, Sep 13, 2016 at 03:11:57PM +0200, Ivan Ogai wrote:
> 
> > > Using LXC, I had a simple script run as a normal user that
> > > 
> > > 1) created an unprivileged container
> > > 
> > > 2) added a user in the container with the same uid and gid as the user
> > >    in the host, let's say 1000
> > > 
> > > 3) modified the configuration of the container in
> > >    ~/.local/share/lxc/example/conf to share their ids:
> > > 
> > >     lxc.id_map = u 0 100000 1000
> > >     lxc.id_map = g 0 100000 1000
> > >     lxc.id_map = u 1000 1000 1
> > >     lxc.id_map = g 1000 1000 1
> > >     lxc.id_map = u 1001 101001 64535
> > >     lxc.id_map = g 1001 101001 64535
> > > 
> > > 4) and added a mount to share a directory, e.g.
> > > 
> > >    /home/$USER/development home/$USER/development none bind,create=dir 0 0
> > 
> > FWIW what I'm hoping to see soon is an option to
> > 
> > 1. overlayfs-mount $HOME/development to $tmpdir
> > 2. shiftfs-mount $tmpdir into the container at $HOME/development
> > 
> > Then after running the container you could look at the airlocked diff
> > before commiting it back into your homedir, in case some bug or trojan
> > in your container tried to do something nefarious.
> 
> That is quite cool indeed, but IIUC it doesn't mount a dir whose changes
> are seen in both ends, no matter if the changes takes place in the host
> or in the guest.

Correct.

And it's worth thinking on more.

The current approach has (at least) two problems:

1. The directory you're sharing is vulnerable to the container
2. The container has full permissions over your host uid (i.e. 1000).

If (1) is not a concern - and if you want changes seen in both directions in
real time then it's not - then we can protect for (2) using just shiftfs,
as it allows us to not map host uid 1000 into the container at all.