Hi, for some reason I'm unable to get the unshare backend working on one of my
machines.

When I try to create an unstable-amd64 tarball to use with sbuild I get this
strange error:

    mmdebstrap --variant=apt --include=build-essential unstable unstable-
amd64.tar
    I: automatically chosen mode: unshare
    I: chroot architecture amd64 is equal to the host's architecture
    I: automatically chosen format: tar
    I: using /tmp/mmdebstrap.panqVhWsFm as tempdir
    W: /etc/subuid is empty
    E: invalid idmap

If I force the creation of the above tarball with root mode and I then try to
use it in sbuild, I get this even bigger error:

    Package: yuzu
    Version: 0-1284+ds-1
    Source Version: 0-1284+ds-1
    Distribution: unstable
    Machine Architecture: amd64
    Host Architecture: amd64
    Build Architecture: amd64
    Build Type: binary

    Use of uninitialized value $nsid in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 401.
    Use of uninitialized value $range in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 401.
    Use of uninitialized value $nsid in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 404.
    Use of uninitialized value $range in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 404.
    Use of uninitialized value $nsid in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 401.
    Use of uninitialized value $nsid in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 404.
    ranges: 2 argc: 5
    newuidmap: Not enough arguments to form 2 mappings
    usage: newuidmap <pid> <uid> <loweruid> <count> [ <uid> <loweruid> <count>
] ...
    newuidmap failed:  at -e line 1.
    child had a non-zero exit status: 256 at -e line 1.
    bad exit status (29): perl -e require 'syscall.ph';pipe my $rfh, my $wfh;my
$ppid = $$;my $cpid = fork() // die "fork() failed: $!";if ($cpid == 0) {close
$wfh;0 == sysread $rfh, my $c, 1 or die "read() did not receive EOF";0 ==
system "newuidmap $ppid  0 60092 1 1  1" or die "newuidmap failed: $!";0 ==
system "newgidmap $ppid  0 60092 1 1  1" or die "newgidmap failed: $!";exit
0;}0 == syscall &SYS_unshare, 268435456 or die "unshare() failed: $!";close
$wfh;$cpid == waitpid $cpid, 0 or die "waitpid() failed: $!";if ($? != 0) {die
"child had a non-zero exit status: $?";}0 == syscall &SYS_setgid, 0 or die
"setgid failed: $!";0 == syscall &SYS_setuid, 0 or die "setuid failed: $!";0 ==
syscall &SYS_setgroups, 0, 0 or die "setgroups failed: $!";exec { $ARGV[0] }
@ARGV or die "exec() failed: $!"; chown 1:1 /tmp/tmp.sbuild.LKlB9A2jh_
    E: Error creating chroot session: skipping yuzu

I've installed this system fairly recently (after the bullseye release), and I
don't have messed with it that much. One thing that comes to my mind that could
be messing with UIDs and GIDs is that I'm using systemd-homed to manage my user
and home directory.

Under systemd-homed, users aren't saved to /etc/passwd, but are retrievable
with glibc's NSS API, i.e. with getent(1) and the various getpwuid(3) C
functions. For instance,

    $ diff /etc/passwd <(getent passwd)
    42a43
    > tachi:x:60092:60092:Andrea Pappacoda:/home/tachi:/usr/bin/zsh

How could I debug and/or solve this issue? I'm a bit lost.

Thank you for your awesome work on mmdebstrap :)


- -- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mmdebstrap depends on:
ii  apt      2.5.4
ii  perl     5.36.0-6
ii  python3  3.10.6-3+b1

Versions of packages mmdebstrap recommends:
ii  arch-test            0.19-1
ii  fakechroot           2.20.1+ds-8
ii  fakeroot             1.29-1
ii  gpg                  2.2.40-1
ii  libdistro-info-perl  1.2
ii  libdpkg-perl         1.21.13
ii  mount                2.38.1-4
ii  uidmap               1:4.13+dfsg1-1

Versions of packages mmdebstrap suggests:
ii  apt [apt-transport-https]  2.5.4
pn  apt-transport-tor          <none>
ii  apt-utils                  2.5.4
pn  binfmt-support             <none>
ii  ca-certificates            20211016
ii  debootstrap                1.0.128+nmu2
ii  distro-info-data           0.56
ii  dpkg-dev                   1.21.13
pn  genext2fs                  <none>
pn  perl-doc                   <none>
pn  qemu-user                  <none>
pn  qemu-user-static           <none>
pn  squashfs-tools-ng          <none>

- -- no debconf information
-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCY7Ai9BQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p+ydAQCvwn3MXvyVE+ZM2rbGbeRb86u25X36
KjgqYW2I8MPpmgD/SsbSU/aB/qjrEY3PdETE1IiUTO9xwI2G0ZbRc5zy5g0=
=Qhaz
-----END PGP SIGNATURE-----

Hi Andrea,

Quoting Andrea Pappacoda (2022-12-31 12:54:35)

Do you have a valid /etc/subuid? Mine says (josch is my username):

josch:100000:65536

How could the error message be improved?

A tarball created in root mode will be bit-by-bit identical to one created in
unshare mode (if SOURCE_DATE_EPOCH was set to the same value).

The error message in sbuild could certainly be improved. Could you try out the
following patch:

diff --git a/lib/Sbuild/ChrootUnshare.pm b/lib/Sbuild/ChrootUnshare.pm
index 9734293a..d48de32d 100644
--- a/lib/Sbuild/ChrootUnshare.pm
+++ b/lib/Sbuild/ChrootUnshare.pm
@@ -105,9 +105,16 @@ sub begin_session {
     my @idmap = read_subuid_subgid;

     # sanity check
-    if (scalar(@idmap) != 2 || $idmap[0][0] ne 'u' || $idmap[1][0] ne 'g') {
-       printf STDERR "invalid idmap\n";
-       return 0;
+    if (   scalar(@idmap) != 2
+        || $idmap[0][0] ne 'u'
+        || $idmap[1][0] ne 'g'
+        || length $idmap[0][1] == 0
+        || length $idmap[0][2] == 0
+        || length $idmap[1][1] == 0
+        || length $idmap[1][2] == 0)
+    {
+        printf STDERR "invalid idmap\n";
+        return 0;
     }

     $self->set('Uid Gid Map', \@idmap);
diff --git a/lib/Sbuild/Utility.pm b/lib/Sbuild/Utility.pm
index 7405055e..5a59b28a 100644
--- a/lib/Sbuild/Utility.pm
+++ b/lib/Sbuild/Utility.pm
@@ -546,34 +546,28 @@ sub read_subuid_subgid() {
        last if ($n eq $username);
     }
     close $fh;
+
+    if ($n ne $username) {
+       printf STDERR "No entry for $username in /etc/subuid";
+       return;
+    }
+
     push @result, ["u", 0, $subid, $num_subid];

-    if (scalar(@result) < 1) {
-       printf STDERR "/etc/subuid does not contain an entry for $username\n";
-       return;
-    }
-    if (scalar(@result) > 1) {
-       printf STDERR "/etc/subuid contains multiple entries for $username\n";
-       return;
-    }
-
     open $fh, "<", "/etc/subgid" or die "cannot open /etc/subgid for reading: $!";
     while (my $line = <$fh>) {
        ($n, $subid, $num_subid) = split(/:/, $line, 3);
        last if ($n eq $username);
     }
     close $fh;
+
+    if ($n ne $username) {
+       printf STDERR "No entry for $username in /etc/subgid";
+       return;
+    }
+
     push @result, ["g", 0, $subid, $num_subid];

-    if (scalar(@result) < 2) {
-       printf STDERR "/etc/subgid does not contain an entry for $username\n";
-       return;
-    }
-    if (scalar(@result) > 2) {
-       printf STDERR "/etc/subgid contains multiple entries for $username\n";
-       return;
-    }
-
     return @result;
 }


Thanks!

cheers, josch

Il giorno sab 31 dic 2022 alle 14:00:54 +01:00:00, Johannes Schauer
Marin Rodrigues <josch@debian.org> ha scritto:

Nope, both /etc/subuid and subgid are empty on my system. They aren't
on my other one that doesn't use systemd-homed, so maybe these are
populated by useradd(8)?

It seems that systemd's issue tracker has a relevant RFE still
unresolved, <https://github.com/systemd/systemd/issues/13717>; maybe it
makes sense to somewhat mention it in sbuild's manual page, it might
not be obvious for users that don't know much about unshare and user
namespaces.

In any case, manually putting tachi:100000:65536 in subuid and subgid
solved the issue. Thanks!

I'm not sure, I really don't know much about this subject :/

Thanks, but I really don't have time know to apply it. Guess I'll let
you know next year ;)

Thanks again!

Quoting Andrea Pappacoda (2022-12-31 16:29:00)

That is correct.

"Uh. The concept of subuids/subgids is just wrong, i am sorry. Static files in
/etc is even worse."

Sounds like that issue will remain open.

But is a user not consciously making the choice for systemd-homed instead of
using the Debian defaults and should thus be prepared for the consequences of
that non-default choice? Recommending to add stuff to /etc/subuid and
/etc/subgid also doesn't sound like the correct choice if the upstream
maintainer of systemd-homed doesn't think it a good idea.

Nice!

In your case, since the files were empty, the line you put in was the correct
solution. In other cases, where there is already content in these files, adding
a new entry is a bit more involved, as the offsets have to be computed
correctly. The reliable way to do it, is to use useradd but that is obviously
not a solution for systemd-homed users.

In my timezone this year only has six hours left, so fair enough. ;)

Thanks!

cheers, josch

Hi,

Quoting Johannes Schauer Marin Rodrigues (2022-12-31 17:44:35)

is there anything left to do for this bug or can it be closed?

Thanks!

cheers, josch

Hi Andrea,

Quoting Andrea Pappacoda (2022-12-31 12:54:35)

I found another actionable in your bug report. mmdebstrap should not
automatically choose unshare mode if that cannot work on your system. To that
end I wrote:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/055e1719b95960496a0cda88535fd00e9a395516

If you like, please try that out on your system with --mode=unshare as well as
with --mode=auto. The messages and logic should be much better now.

If you cannot apply that patch, since mmdebstrap is a single script, you can
also just download the perl script and run it:

https://gitlab.mister-muffin.de/josch/mmdebstrap/raw/branch/main/mmdebstrap

Tell me what you think!

This is similar to #1032489, so I'm putting Dima in CC who can try this as
well. :)

Thanks!

cheers, josch

We believe that the bug you reported is fixed in the latest version of
mmdebstrap, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1027429@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Johannes Schauer Marin Rodrigues <josch@debian.org> (supplier of updated mmdebstrap package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 18 Mar 2023 00:33:00 +0100
Source: mmdebstrap
Architecture: source
Version: 1.3.4-1
Distribution: unstable
Urgency: medium
Maintainer: Johannes Schauer Marin Rodrigues <josch@debian.org>
Changed-By: Johannes Schauer Marin Rodrigues <josch@debian.org>
Closes: 1027429 1032489
Changes:
 mmdebstrap (1.3.4-1) unstable; urgency=medium
 .
   * New upstream version 1.3.4
      - more safeguards before automatically choosing unshare mode (closes:
        #1027429, #1032489)
Checksums-Sha1:
 87c9a980af61c9cef8ec40ce5078d995f5ad142c 2433 mmdebstrap_1.3.4-1.dsc
 1cebda52cd93b0f7ae99a8cdbaa46d67f558d17e 142172 mmdebstrap_1.3.4.orig.tar.gz
 01441a2a97a50e55352c8ea042abbcc28503bf77 15680 mmdebstrap_1.3.4-1.debian.tar.xz
Checksums-Sha256:
 ecf792987389ca1a0bee05e7befcdb99dd0cea9e59bd9ce720b9b1cd5c3948e7 2433 mmdebstrap_1.3.4-1.dsc
 06b14e964aa4693d712b8f48caa6f2c6ad4284ec9b7eb1b3ebd0a2262bd51201 142172 mmdebstrap_1.3.4.orig.tar.gz
 3ffc461979b3d6b222a9ee91243aa768c63afb31eaa0cc3a2c542dff4a2a5675 15680 mmdebstrap_1.3.4-1.debian.tar.xz
Files:
 c253fcc7e1b6721d8d9e3b7d99a59e9f 2433 admin optional mmdebstrap_1.3.4-1.dsc
 df01fb9180f963ef98b3c38e90999b5d 142172 admin optional mmdebstrap_1.3.4.orig.tar.gz
 7deaa8e6d2daf02ef675f1228b23f9ad 15680 admin optional mmdebstrap_1.3.4-1.debian.tar.xz
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmQVAiwACgkQ8sulx4+9
g+GYIA//aK7JMKUz2obWis2L6K8WYqjPnEz77LLcE8Eodjz4LPG1Bbv41OMXKW/l
lr8zAoMmK0qKdMrPOQnYOhAgVc1gCw5drEe6agqpWHlMCHe94f4erg7mvVuige/B
JJ6s1sppKNuK6Q9HcBTe+b55kdkSm7nCYyXtu+8kfzsGsW5l/+GiEdXzeR5VD8QF
2oeD6/X36fFJ9CYZyem0HCcgWoPYBZmUVRui7ZV73RAMDDLCdt6620bDifDGY6y7
udvwFlOYXGBZJE2M0t/YvT0DtgFOZX7TUX4Nf/vcCv4BC3yRQiOUKz+DKdMX5I47
NfmMYn0HJZcAGFOofywOgw2FfdruJhQJ+smY5ckobWirD/jMtyhUpYihqTBpmdDx
l93jm9OEs4pYDos38L+tBx/seDC1LMiQ4pXZHi2I7I1OyIapOpeqZOyTDiqs5G0T
FgxluMcla786rNuZqHGsKwI5Bo7EMBWK/3lf28SINf/1nBfzG8xdqjYQjpeB4fGM
VDHaiG/vvxzeB4JP3aBhp72v+/GlsRXY7ZsrofUEOTQaUT04Lw2s22tpEaMjWewX
uEWpqS556JVwxU5dBamZwwmnzmuvEyBK1uVfiEhH5pdFbJnMwtnDQY6B3S6FxpXY
E6KQwYNdmTdO2p+uW3/YJRVKdaocBRt+uu6YS7fu03jdH2ZvE9A=
=xhk3
-----END PGP SIGNATURE-----

Il giorno gio 16 mar 2023 alle 03:57:42 +01:00:00, Johannes Schauer
Marin Rodrigues <josch@debian.org> ha scritto:

Hi Josch, sorry for my super late reply and thanks for your fix! The
error message is much cleaner now, and it gives the user a useful
pointer so that the issue can be manually fixed/worked around.

Thanks again, keep up with the great work :D