Bug#932103: RFP: fuidshift -- remap a filesystem tree to shift one set of UID/GID ranges to another
On 15/07/2019 06:16, Nicholas D Steeves wrote: > Package: wnpp > Severity: wishlist > > Package name: fuidshift > Version : 3.0 > Upstream Author : Name > 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. > > I learned about this tool via the following document: > https://github.com/BenSartor/unprivileged-lxc-containers > > Here is the upstream description: > > 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 > :::. > 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. > > An alternative to this, written on C, is uidmapshift that can be found at https://code.launchpad.net/~serge-hallyn/+junk/nsexec Its packaged for Arch, see: https://wiki.archlinux.org/index.php/Linux_Containers#Converting_a_privileged_container_to_an_unprivileged_container signature.asc Description: OpenPGP digital signature
Bug#932103: RFP: fuidshift -- remap a filesystem tree to shift one set of UID/GID ranges to another
Hi, On Wed, Jul 17, 2019 at 01:55:06AM +0200, Vincent Tondellier wrote: > On Tuesday 16 July 2019 23:11:24 Florian Weimer wrote: > > * Nicholas D. Steeves: > > > Package name: fuidshift > > > Version : 3.0 > > > Upstream Author : Name > > > 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 > > ... > > > 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* > That's a good short description :-) > 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. > > 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 signature.asc Description: PGP signature
Bug#932103: RFP: fuidshift -- remap a filesystem tree to shift one set of UID/GID ranges to another
On Tuesday 16 July 2019 23:11:24 Florian Weimer wrote: > * Nicholas D. Steeves: > > Package name: fuidshift > > Version : 3.0 > > Upstream Author : Name > > 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 ... > 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. > 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.
Bug#932103: RFP: fuidshift -- remap a filesystem tree to shift one set of UID/GID ranges to another
* Nicholas D. Steeves: > Package name: fuidshift > Version : 3.0 > Upstream Author : Name > 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. > > I learned about this tool via the following document: > https://github.com/BenSartor/unprivileged-lxc-containers > > Here is the upstream description: > > 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 > :::. > 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.
Bug#932103: RFP: fuidshift -- remap a filesystem tree to shift one set of UID/GID ranges to another
Package: wnpp Severity: wishlist Package name: fuidshift Version : 3.0 Upstream Author : Name 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. I learned about this tool via the following document: https://github.com/BenSartor/unprivileged-lxc-containers Here is the upstream description: 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 :::. 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. Regards, Nicholas
