@brauner@stgraber:
Thanks to both of you.
It is now working (I also tested it within containers).
Some additional questions:
Would you mind if I set up a github repo for shiftfs-dkms?
Even though the setup is fairly easy (just as you said), for users like me, it would probably be a good help.
I would not necessarily include shiftfs.c; I would just put a link into the Readme.
So people would always use the most recent version.
I am also working on a debian package, but i guess more professional users should do it for the official debian repos.
1.a) I guess the trick with putting the SHIFTFS_MAGIC parameter into shiftfs.c is not so good for packaging?
Am i right to assume that the disk device (with shift: true) always “mounts” the folder for/to the standard user (in my case: uid 1000)?
And is it possible to change that?
Having a Github repo with the needed dkms bits sounds good, go ahead!
You can include all that’s needed and maybe just put a script to re-sync things.
The SHIFTFS_MAGIC bit could probably be passed as a define directly to the compiler to avoid needing any code change at all.
As for how shiftfs work, we don’t shift to a particular user, shiftfs instead converts between user namespace ranges. So when you pass a mount with shift=true, the uid/gid you see in the container are now identical to what you would see outside of the container. It’s not tied to a single uid/gid.
@stgraber : How is it handled from the security / access right point of view? Does the unprivileged container really have the uid/gid of ‘outside’ from the host point of view, 1000 in the example above? Said otherwise (if I’m not clear ), if user 1000 on the host has R/W access to the shared folder, does the container’s user 1000 has R/W access on the bind-mounted folder?
Thank you for the explanation!
[Edit] I think I found the answer to my question, by reading the example there: LXD 3.16 has been released . So if I’m not wrong, yet the container and host now share the use the same IDs for that folder, so if a user in container has that ID, it has the right assignated to that host’s folder. If I’m wrong, please correct me.
my thought: Waow, LXD is powerful and so versatile
After test, I realize that a consequence of shifts is that a document created by the container’s root will appear on the host as created by “root” like it was the host’s root and not say by user 1,000,000. I feel uncomfortable with that. Isn’t it dangerous?
It’s only really a problem if you’re dealing with extra mounts which are visible to unprivileged/untrusted users on the host and that filesystem isn’t mounted with nosuid/nodev. In that case, root in the container can create a setuid binary or a device node which the unprivileged/untrusted user on the host can then exploit.
If the container itself is on shiftfs or you’re attaching a custom storage volume, the source of those volume is kept completely inaccessible from unprivileged users on the host, to avoid any such issues.
But when you’re attaching a disk device with shifted=true, then yes, you need to keep this in mind.
Yeah, if setuid is possible on a path that’s visible to an unprivileged user on the host, root in the container could say copy /bin/sh to that path, chown 0:0 and chmod u+s it, making it setuid root for anyone on the host who’s allowed to run it.
Ok, good to know (though of course unlikely, many security guidelines must be broken for that ) .
Maybe a stupid question (and also very unlikely scenario) but does that apply to sudo users (instead of root) as well (lets assume a no password option)?
Yeah, anyone who can set a setuid bit inside the container would be an issue. sudo restricted to a small set of commands could avoid this, though there often are ways to abuse such a setup
Stéphane, where do you set nosuid/nodev/noexec when bind mounting ? Is it when doing the “lxc config add […] disk […]” ? Or by manually editing the CT configuration?
So to be the safest, I’d actually do it on the source mount to avoid any potential changes on the bind-mounts.
If you have a separate partition for your /home, then add nosuid,nodev to its mount options in /etc/fstab.
If you don’t, you should be able to add an extra line like /home /home none bind,nodev,nosuid 0 0 which may do the trick (bind-mounts are weird sometimes, so you’ll want to make sure that it’s correct in /proc/mounts).
Maybe that should be included in the documentation?
I just saw that the option “defaults” (fstab) does include “suid, dev”.
And maybe some people will include host folder in their container server setups.
Though it is still unlikely to have a malicious user on the host, it is not impossible, as some people share servers (in this case i mean computers of course) with others.
And because of the use of unpriviledged containers, people will assume to be save from such problems, while they are not.
It’s actively used in production by many users. I believe we may be in good enough shape now that we can start enabling it for new installs before turning it on for everyone.
), if user 1000 on the host has R/W access to the shared folder, does the container’s user 1000 has R/W access on the bind-mounted folder?