Secure and user friendly mounts for unprivileged


Did anything change in recent LXD versions to allow unprivileged containers to write access user directories in secure and user friendly way? By that I mean:

  1. No write for everybody mode on a host machine
  2. No read only files created by container on a host
  3. No broken permissions if a host is rebooted
  4. No mounting of /, $HOME and .ssh unless explicitly asked

While I can script p.4, the first 3 points deem an unsolvable problem for me.

An issue that was preventing read only mounts with shiftfs enabled (which shifts the uid/gid of the mount into the container) has been recently fixed, so that may be of interest.


Thanks. I could make the volume writable after enabling shiftfs with LXD and using shift=true for adding disk devices:

lxc config device add $NAME $NAME-shared disk source=$PWD \
  path=/root/$NAME shift=true

But I am still not sure it is secure after reading this thread on setuid:

I am not sure that getting into details of what setuid is and how it works is user friendly approach to security. Maybe there is no concern in this case? Is there a code I can run on guest/host to check if my mount is exploitable to this setuid attack?

Are you wanting a readonly mount? I’m not really clear what you are asking for.

I want rw mount without security implications of setuid attack (whatever it is).

@stgraber @brauner is this possible?

If the filesystem on the host is mounted with nosuid, then this would avoid anyone running setuid binaries from it. However all it would take is one system reconfiguration missing the nosuid to be back in trouble.

I don’t know if the new version of this mechanism (idmapped mounts) would allow for putting an irreversible restriction on the container side mount so that no suid permissions may be written through it, I doubt that such a mechanism is currently part of it, but maybe it can be added to the kernel without too much difficulity.

1 Like

The default filesystem for user’s $HOME on Ubuntu is mounted without nosuid. I assume that makes shift=true unsafe to use on user systems for running random scripts from GitHub in isolation.

Another problem with shift=true is that condition 2. No read only files created by container on a host is not fulfilled. The files created from guest system are owned by root:root on host. If I would do git pull from the guest, that would create ro files that then will give errors on subsequent git operations from the host.