Quoting Francesco Poli (2021-03-29 23:26:27) > 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?
Theoretically your user can indeed use any uid from that range for its purposes
but in practice I never saw a program choose the uid mapping arbitrarily.
Instead (and that's also what mmdebstrap does) it will choose the first subuid
that you can use for the root user (uid 0) and then all the remaining uids from
then on. So my /etc/subuid says:
josch:100000:65536
So my root user in unshare mode will always get the uid 100000 as seen from the
outside and a user with uid 1000 inside the unshare environment will have uid
101000 as seen from the outside.
This is what happens when you use tools like lxc-usernsexec without the -m
option which allows you to use a custom range. Other programs require you to
know your subuid offset from /etc/subuid and you have to provide it manually
(see systemd-nspawn in the mmdebstrap man page).
But I don't think that this kind of information belongs into the mmdebstrap man
page.
> > > 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?
Not necessarily. If your $HOME is readable by "everybody" and if you create a
directory inside your $HOME which allows "everybody" to create stuff in it then
you can use that as your $TMPDIR. Best even if you chmod that directory with
the sticky bit in the same way as it's done for /tmp. If the directory is not
directly inside your $HOME, then all directories in the path must be world
readable. Only the last component must be world writable.
I think the "world writable" assumption is a fair one for a temporary
directory.
> 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 ?
How many chroots do you want to put into your /tmp?
$ mmdebstrap unstable | wc -c
...
196625920
That's 188 MB.
> /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!
That depends on what you want to do inside that qemu environment. And it's
totally possible to create a 10 GB disk image in your $HOME while only using
200 MB in your /tmp for the chroot.
> > > 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?
It cannot help you. The option is undocumented because its interface is
unstable. What the --unshare-helper option does is to provide you similar
functionality to lxc-usernsexec -- lxc-unshare -s 'MOUNT|PID|UTSNAME|IPC'
without installing the lxc package.
> Thanks for your time and great patience. :-)
You are welcome. I would love to hear things I could add to the mmdebstrap man
page. I fear that an introduction to Linux user namespaces would not be
fitting.
signature.asc
Description: signature
