On Tue, Jan 16, 2024 at 12:21:46AM +0100, Francesco Poli wrote: > Why is my first subuid not my user, but a different user? > Is it by design?
Yes, this is by design. The use of subuids provides isolation. It's not that you have just one, but you have a whole range of uids - the first of which happens to be mapped to root. In particular, this mapping must be constructed in such a way that every uid inside the namespace is mapped to a different uid outside the namespace. Hence, you really need a lot of uids to construct such a namespace. Then the use of different uids serves isolation: Processes that use the namespace have uids inside your subuid range outside and then regular permission rules prevent such processes from doing bad things with your user (such as killing your processes or messing with your files). While we do not technically need this property here (as e.g. fakeroot/fakechroot does not provide such isolation either), it still is a safety-net for things that might go wrong that we'd like to not give up. > Or can my first subuid be forced to become my user? In principle, yes. The mapping currently is: 0 - 65535 -> first_subuid - first_subuid+65535 This is the same mapping that you get with unshare --map-auto. Instead we could also map like this: 0 -> your_uid 1 - 65535 -> first_subuid - first_subuid+65534 This is roughly what you get with unshare --map-root-user --map-auto. mmdebstrap does not allow you to configure this aspect at this time. > Well, performance was not an issue here. > The copy of > > $ ls -lFs --si sid_amd64.img > 690M -rw-r-xrwx 1 $USER $USER 2.3G Jan 15 23:26 sid_amd64.img* > > was really quick. Probably. Copying huge chunks of data probably just feels wrong and technically isn't. We could also generate the file in $TMPDIR in general (hoping it is backed by tmpfs and that the system performing the image build has at least 4GB ram) and then copy it to the final destination in general. That's usability beating performance. > However, even on a mechanical hard disk drive, I would be more than > willing to spend some more time in the copy operation. After all, if I > understand correctly, the image will only be created once, and then kept > up-to-date with "sbuild-qemu-update" (which does not require superuser > privileges, does it?). Alternatively, you may periodically recreate your image. The official Debian buildd network could also be using sbuild-update to update its chroots, but instead they periodically recreate them. > Would the use of the .qcow2 format even further help in this? The qcow2 format is not using sparseness. Hence, copying cannot inflate its size. Also qcow2 can be inline-compressed which can further reduce the image size. autopkgtest will produce an overlay image in any case rather than modify your base image, so you don't grow it over time while using it. > d. configure sbuild-qemu and learn to use it to build Debian packages Does this provide significant advantages over sbuild in unshare mode? > e. report to you and/or Christian Kastner (and suggest possible > improvements for mmdebstrap-autopkgtest-build-qemu and/or > sbuild-qemu) I suspect mmdebstrap-autopkgtest-build-qemu very much is unfinished. We got it into a barely-works. I think making this all more useful eventually requires finding a solution for crossing uid boundaries in a sane way. At this time, I see two fairly generic ways to do this: a) Have a very simple proxy fuse driver in the initial namespace and mount it inside the target namespace. That way an individual directory from a different user can be exposed to the namespace without granting full access. (Good containment, non-trivial setup, slight performance degradation.) b) Map the calling user in the user namespace. We don't have to map the user to root. We can map it to some high uid > 65535. Any process that has CAP_DAC_OVERRIDE (and that capability is initially available and typically available to any process running as uid 0 inside) can also access files by your user. (Bad containment, easy setup, no performance impact.) Helmut
