On Sun, 28 Mar 2021 21:04:24 +0200 Johannes Schauer Marin Rodrigues wrote: > Quoting Francesco Poli (2021-03-28 20:24:12) > > Well, the problem is probably my total ignorance about unshare, user > > namespaces, and so forth... > > > > First of all, I do not know what exactly subuid and subgid are. > > man subuid? ;)
OK, I have read subuid(5) man page. Now I know which subordinate UIDs my user can use within a namespace. But do I understand correctly that I cannot predict which one will be used next time I try to start mmdebstrap in unshare mode? > > > I suppose they have something to do with the uid and gid seen from > > within the namespace (I noticed that the temporary directory was > > created with high values of uid and gid, not corresponding to any > > existing user or group). > > Correct. So if some directory on the path of your $TMPDIR is not accessible by > that user with the very high uid/gid, then it obviously cannot create the > chroot directory. This seems to imply that I cannot use anything within my home directory as $TMPDIR ... Is this the case? If this is indeed the case, and /tmp is too tightly sized (SSD partition of size about 870 MB), where can I put my $TMPDIR ? /dev/shm seems to be risky (its size is about 8.3 GB, less than half the system memory). Suggestions? I am assuming that creating a QEMU/KVM image of size, say, 200 MiB is not enough as an autopkgtest-virt-qemu testbed. I was aiming at 4 GiB or 8 GiB, but maybe I am off-track here. Please advise! > > > I tried to take a look at some man pages (unshare(1), > > user_namespaces(7), ...) in order to understand something more, but > > there seems to be much more information than the basics, and I failed > > to pinpoint where I can read the bare minimum I need to know... > > My bad, of course! > > But anyway, if you know a good reference to a short explanation of the > > topic (ideally a man page), I would suggest to cite it in the > > mmdebstrap man page. > > Unfortunately, I do not know of such a reference. All I learned to add unshare > support to mmdebstrap was from reading source code of other tools. :( I see, the good old "Use the Force, read the Source!". ;-) > > > After that, I can guess that the problem is that, inside the unshared > > namespace, there's no permission to create/write files in my > > ~/Downloads directory. > > Or one of its parent. You also need more than write access. You also need read > access. And directories need to be executable. > > > But what is not clear to me is what I am supposed to do with this > > problem. > > > > What would you suggest? > > Your whole problem started because you decided to deviate from the default and > chose a different TMPDIR. If you use custom options, then you should know what > you are doing. If you don't set TMPDIR, then it will work. If you do set > TMPDIR, then you have to make sure that whatever path TMPDIR points to is > setup > in a way that the unshared user is able to access it and write stuff into it. As said above: I chose a different TMPDIR, since /tmp turned out to not be big enough. I am open to suggestions on how to work around this issue. And by the way, I still do not understand how the --unshare-helper can help me... as long as it can help me at all! Could you please clarify? Thanks for your time and great patience. :-) -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpTQZCOh3x3a.pgp
Description: PGP signature
