Bug#932103: RFP: fuidshift -- remap a filesystem tree to shift one set of UID/GID ranges to another

[Florian Weimer]

Package name : fuidshift
Version : 3.0
URL : https://github.com/lxc/lxd/tree/master/fuidshift
License : Apache 2.0
Programming Lang: Go
Description : remap a filesystem tree to shift one set of UID/GID
ranges to another
Fuidshift is useful for converting privileged containers to
unprivileged ones, and also to adapt a container master to multiple
users' authorised subuid and subguid ranges. It also sounds like it
might be useful for fixing up cases where --numeric-owner should have
been used, but where it would be too labour-intensive to manually chown.
https://github.com/BenSartor/unprivileged-lxc-containers
This tool lets you remap a filesystem tree, switching it from one
set of UID/GID ranges to another.
This is mostly useful when retrieving a wrongly shifted filesystem tree
from a backup or broken system and having to remap everything either to
the host UID/GID range (uid/gid 0 is root) or to an existing container's
range.
A range is represented as <u|b|g>:<first_container_id>:<first_host_id>:<size>.
Where "u" means shift uid, "g" means shift gid and "b" means shift
uid and gid.
https://github.com/lxc/lxd/blob/81b81b9ace3064c8065319f4e984378244587d80/fuidshift/main_shift.go#L26-L36
It's part of the LXD project, but I'm not sure if it's as difficult to
package as LXD itself, which is one reason why I've CCed the Go team.
I also wonder if the best way to get this into Debian would be a
src:lxd that produces bin:fuidshift.

How does this compare to (or interact with) newuidmap and newgidmap
from uidmap?

There's a push to force uidmap on everyone, with tight integration
into NSS. If there's a competing scheme, it would be helpful to know
about it.

[Vincent Tondellier]

Post by Florian Weimer

Package name : fuidshift
Version : 3.0
URL : https://github.com/lxc/lxd/tree/master/fuidshift
License : Apache 2.0
Programming Lang: Go
Description : remap a filesystem tree to shift one set of UID/GID
ranges to another

...

Post by Florian Weimer
How does this compare to (or interact with) newuidmap and newgidmap
from uidmap?

They do very different things.

Let me try a short description :
newuidmap - set the uid mapping of a user namespace (from manpage)
fuidshift - shift the uid/gid of files *on disk*

fuidshift is basically a recursive
chown $(( $(stat -c '%u' "$path") + $uidshift )) "$path"

It does not use or configure user namespaces or containers.

It's useful for the creation of containers images, for example when the
container root filesystem is read-only (squashfs) and the container engine
can't change the uids at runtime (see for example systemd-nspawn --private-
users=pick / --private-users-chown).

So fuidshift may be used to prepare a directory for later use by newuidmap,
but that's about it.

Post by Florian Weimer
There's a push to force uidmap on everyone, with tight integration
into NSS. If there's a competing scheme, it would be helpful to know
about it.

[Nicholas D Steeves]

Hi,

Post by Vincent Tondellier

Post by Florian Weimer

Package name : fuidshift
Version : 3.0
URL : https://github.com/lxc/lxd/tree/master/fuidshift
License : Apache 2.0
Programming Lang: Go
Description : remap a filesystem tree to shift one set of UID/GID
ranges to another

...

Post by Florian Weimer
How does this compare to (or interact with) newuidmap and newgidmap
from uidmap?

They do very different things.
newuidmap - set the uid mapping of a user namespace (from manpage)
fuidshift - shift the uid/gid of files *on disk*

That's a good short description :-)

Post by Vincent Tondellier
fuidshift is basically a recursive
chown $(( $(stat -c '%u' "$path") + $uidshift )) "$path"
It does not use or configure user namespaces or containers.
It's useful for the creation of containers images, for example when the
container root filesystem is read-only (squashfs) and the container engine
can't change the uids at runtime (see for example systemd-nspawn --private-
users=pick / --private-users-chown).
So fuidshift may be used to prepare a directory for later use by newuidmap,
but that's about it.

It's also useful as part of redistributing namespace blocks of
uids/guids among new/different users/groups.

One specific case I think it would be useful for is this: a user that
started with Debian's default LXC configuration, then learned how
insecure that was, and then wants to preserve their work while
migrating the container to an unprivileged one; this happened to me
once and I lost an hour or two recreating my customisations. I have a
friend who would appreciate this tool to save time fixing up such a
situation.

Post by Vincent Tondellier

Post by Florian Weimer
There's a push to force uidmap on everyone, with tight integration
into NSS. If there's a competing scheme, it would be helpful to know
about it.

Sorry, I'm not sure, but as fuidshift is part of the LXD project I
would imagine that it will be well supported moving forward. eg: if
there will ever (hypothetically) be something like an aclmap that maps
POSIX or NFSv4 acls container-to-host. It's definitely better
maintained than other tools that do this recursive chown, and AFAIK
LXD is going to eventually be packaged for Debian, so bin:fuidshift
from src:lxd makes sense to me. Is this not the case?


Thank you for your comments!
Regards,
Nicholas

[Vincent Tondellier]

Hello,

Post by Nicholas D Steeves
LXD is going to eventually be packaged for Debian, so bin:fuidshift
from src:lxd makes sense to me.

I see that fuidshift is now part of the lxd-tools packages, so I think that
this RFP can be closed.

Regards,
Vincent