Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #1130921 > unrolled thread
| Started by | Andrea Pappacoda <andrea@pappacoda.it> |
|---|---|
| First post | 2022-12-31 13:00 +0100 |
| Last post | 2022-12-31 17:50 +0100 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.debian.bugs.dist
Bug#1027429: mmdebstrap: unshare backend not working Andrea Pappacoda <andrea@pappacoda.it> - 2022-12-31 13:00 +0100
Bug#1027429: mmdebstrap: unshare backend not working Johannes Schauer Marin Rodrigues <josch@debian.org> - 2022-12-31 14:10 +0100
Bug#1027429: mmdebstrap: unshare backend not working Andrea Pappacoda <andrea@pappacoda.it> - 2022-12-31 16:40 +0100
Bug#1027429: mmdebstrap: unshare backend not working Johannes Schauer Marin Rodrigues <josch@debian.org> - 2022-12-31 17:50 +0100
| From | Andrea Pappacoda <andrea@pappacoda.it> |
|---|---|
| Date | 2022-12-31 13:00 +0100 |
| Subject | Bug#1027429: mmdebstrap: unshare backend not working |
| Message-ID | <FIIGR-eAfw-3@gated-at.bofh.it> |
Package: mmdebstrap
Version: 1.2.4-1
Severity: normal
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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-----
[toc] | [next] | [standalone]
| From | Johannes Schauer Marin Rodrigues <josch@debian.org> |
|---|---|
| Date | 2022-12-31 14:10 +0100 |
| Message-ID | <FIJMB-eB8R-11@gated-at.bofh.it> |
| In reply to | #1130921 |
Hi Andrea,
Quoting Andrea Pappacoda (2022-12-31 12:54:35)
> 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
Do you have a valid /etc/subuid? Mine says (josch is my username):
josch:100000:65536
How could the error message be improved?
> If I force the creation of the above tarball with root mode
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).
> 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.
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
[toc] | [prev] | [next] | [standalone]
| From | Andrea Pappacoda <andrea@pappacoda.it> |
|---|---|
| Date | 2022-12-31 16:40 +0100 |
| Message-ID | <FIM7L-eCve-1@gated-at.bofh.it> |
| In reply to | #1130933 |
Il giorno sab 31 dic 2022 alle 14:00:54 +01:00:00, Johannes Schauer Marin Rodrigues <josch@debian.org> ha scritto: > Do you have a valid /etc/subuid? Mine says (josch is my username): > > josch:100000:65536 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! > How could the error message be improved? I'm not sure, I really don't know much about this subject :/ > The error message in sbuild could certainly be improved. Could you > try out the > following patch: Thanks, but I really don't have time know to apply it. Guess I'll let you know next year ;) Thanks again!
[toc] | [prev] | [next] | [standalone]
| From | Johannes Schauer Marin Rodrigues <josch@debian.org> |
|---|---|
| Date | 2022-12-31 17:50 +0100 |
| Message-ID | <FINdw-eD8L-11@gated-at.bofh.it> |
| In reply to | #1130952 |
Quoting Andrea Pappacoda (2022-12-31 16:29:00) > Il giorno sab 31 dic 2022 alle 14:00:54 +01:00:00, Johannes Schauer > Marin Rodrigues <josch@debian.org> ha scritto: > > Do you have a valid /etc/subuid? Mine says (josch is my username): > > > > josch:100000:65536 > > 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)? That is correct. > It seems that systemd's issue tracker has a relevant RFE still unresolved, > <https://github.com/systemd/systemd/issues/13717>; "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. > 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. 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. > In any case, manually putting tachi:100000:65536 in subuid and subgid solved > the issue. Thanks! Nice! > > How could the error message be improved? > I'm not sure, I really don't know much about this subject :/ 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. > > The error message in sbuild could certainly be improved. Could you try out > > the following patch: > Thanks, but I really don't have time know to apply it. Guess I'll let you > know next year ;) In my timezone this year only has six hours left, so fair enough. ;) Thanks! cheers, josch
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.bugs.dist
csiph-web