Trying out `shiftfs`

Yes, shiftfs makes it so the filesystem uid/gid match inside and outside the container.


@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 :wink: ), 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 :slight_smile:

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?

Right, that’s indeed exactly what shiftfs does.

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.

So you are talking about unwanted root access for a user on the host (worst case of course)?

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 :slight_smile: ) .
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 :slight_smile:

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).

1 Like

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.

Is shiftfs stable for production machines at the moment? Or is it still in a ‘test phase’ ?

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.

@brauner thoughts?

1 Like

It is pretty stable at this point. There are a few minor glitches but nothing major that we’ve seen for a long time.

1 Like

Perfect, i’ll enable it now.

Hi, I’m interested in using the shiftfs kernel module on a different distribution (Arch Linux).

What’s the latest progress of getting this upstreamed into the Linux kernel?

We don’t expect it to ever get mainlined, instead we’re working on an equivalent feature through VFS changes using the new VFS kernel API.

For now though, there is a dkms package you can use which is known for working on a few other distros.

which @toby63 maintains

1 Like

Can I use raw.idmap as a safe alternative to shiftfs?

@stgraber Could you maybe update this article, so it reflects the recent situation with idmapped mounts?
(I know of course that this functionality is usually enabled by default, but still it is interesting for people who want to share folders and volumes between host/container or between containers, to know that they can do it without the shiftfs module now)

Additional question:
Are and will the commands be the same (e.g. shift: true
type: disk) as described for example in my howto (LXD usecases of shiftfs (volume-/disk-share)) or will they change?

All the LXD behavior is identical, same config keys, same everything. It will just favor idmapped mounts over shiftfs when usable. Once we have a kernel where that’s true for all cases we care about, shiftfs will go away.

We’re currently hoping this will happen with Ubuntu 22.04 so we don’t need to support shiftfs for another 5 years or more.

1 Like