Hi, Quoting Francesco Poli (2019-11-17 16:56:48) > > Quoting Francesco Poli (2019-11-17 16:06:05) > > > I am giving it a try, but I am getting an error I am not quite sure to > > > understand: > > > > > > [...] > > > > > > I: automatically chosen mode: fakechroot > > there is your problem. If you are not executing mmdebstrap with superuser > > privileges and if you you did not manually specify which --mode to use, > > then it will look for some way to create the tarball that works on your > > system. For you it picked fakechroot. > [...] > > Well, I was trying the command you have previously suggested... > > I understand that automatic mode depends on which packages I have > installed on my system and on my sysctl configuration.
Yes, correct.
> The fact is: I was running as a regular user.
> I have:
>
> $ /sbin/sysctl kernel.unprivileged_userns_clone
> kernel.unprivileged_userns_clone = 0
>
> And I have fakechroot on my system, just because mmdebstrap recommends
> it:
>
> $ aptitude why fakechroot
> i mmdebstrap Recommends fakechroot
>
> Hence, everything conspired to make mmdebstrap choose that mode!
Also correct.
> Maybe the recipe you suggested should be improved to address this issue with
> the selection of the mode...
Before doing that I'll see if this could be fixed by changing something in
either fakechroot or in update-initramfs.
> > That mode works by using an LD_PRELOAD library to fake root permissions for
> > all executed programs. Sometimes this fails badly and the postinst script
> > of update-initramfs is a known maintainer script that doesn't work under
> > fakechroot mode. I briefly looked into the problem a few days ago but
> > couldn't immediately see what was wrong. So this is not a bug in
> > mmdebstrap. It is maybe a bug in fakechroot or maybe something could be
> > done different by the postinst script of update-initramfs. I don't know
> > whether either maintainer considers what you see a bug. You can try and
> > file one and see if you get this fixed somehow.
>
> I can try and report bugs, although I don't fully understand what's
> going on, and hence I will need your help to explain. Are you willing
> to join this bug reporting effort?
I'll take care of it. Before filing a bug I'll first see if I can maybe find
the root cause of it.
> Anyway, I am not sure I understand how *you* create an autopkgtest QEMU/KVM
> testbed with mmdebstrap. I thought you were successfully using the recipe you
> suggested. Is it not the case? How do *you* do that?
I see two possibilities:
1. back then when I wrote the docs a year ago, the bug in update-initramfs or
fakechroot might not've existed yet
2. maybe I had "kernel.unprivileged_userns_clone = 1" set and thus unshare
mode was selected during my testing
> > Another way to solve the problem is by choosing a different mode. If you
> > don't
> > mind using superuser privileges, you could run mmdebstrap as root.
> I really mind! ;-)
Great! :D
> Creating QEMU/KVM images without superuser privileges was the whole
> point of giving mmdebstrap a try.
> Otherwise I would just be using autopkgtest-build-qemu, as I said in the
> original bug report...
You could also file a bug report against vmdb2 (which is used by
autopkgtest-build-qemu) and ask its maintainer whether they would consider
adding root-less operation to it. As shown by mmdebstrap it's possible to
create a qemu autopkgtest image without superuser privileges. Maybe other tools
can gain that functionality as well?
> > Alternatively, you could also try --mode=unshare which uses linux user
> > namespaces to avoid using root privileges to build your tarball.
>
> This seems to require setting "kernel.unprivileged_userns_clone=1" with
> sysctl. But, after having a look at #898446, I am under the impression
> that doing so would reduce the security of my system...
I cannot give you good advice about security.
But if all you are creating a Debian chroot and running only software from
Debian, then you are trusting that software already, no?
I mean, we are not talking about using user namespaces to contain a potentially
malicious proprietary application but about the same code which otherwise
already is running with superuser privileges on millions of systems.
> Any other possibility to create autopkgtest QEMU/KVM images without root
> privileges?
You could also try using --mode=proot.
Thanks!
cheers, josch
signature.asc
Description: signature
