Bug#1109128: sbuild --chroot-mode=unshare fails with Permission denied if the tarball does not contain /
For information, I proposed pbuilder with a patch to include . in its produced tarball: https://salsa.debian.org/pbuilder-team/pbuilder/-/merge_requests/39 Samuel
Bug#1109128: sbuild --chroot-mode=unshare fails with Permission denied if the tarball does not contain /
Samuel Thibault, le ven. 11 juil. 2025 23:38:55 +0200, a ecrit: > Helmut Grohne, le ven. 11 juil. 2025 23:30:37 +0200, a ecrit: > > > If so, then the easier option would be to let sbuild create the tarball, > > > and > > > not point it to the pbuilder tarball. > > > > Yeah. That's what we ended up doing. > > But I really like maintaining the state of my tarballs with pbuilder, so > I'd really like sbuild to be able to use them. More precisely, I *need* to tune my chroots in ways that sbuild doesn't currently seem to support, and probably won't all support (not only adding some repositories, but also other components, other suites, possibly tune some configuration, etc.) so unless sbuild grows some "login --save-after-login" support, I *have* to keep using pbuilder for my various workflows while staying sane (it's *way* simpler to use a shell to do what I need than use a flurry of options that I have to look up in the sbuild manpage). Samuel
Bug#1109128: sbuild --chroot-mode=unshare fails with Permission denied if the tarball does not contain /
Helmut Grohne, le ven. 11 juil. 2025 23:30:37 +0200, a ecrit: > > If so, then the easier option would be to let sbuild create the tarball, and > > not point it to the pbuilder tarball. > > Yeah. That's what we ended up doing. But I really like maintaining the state of my tarballs with pbuilder, so I'd really like sbuild to be able to use them. Samuel
Bug#1109128: sbuild --chroot-mode=unshare fails with Permission denied if the tarball does not contain /
Hi Chris, On Fri, Jul 11, 2025 at 11:17:39PM +0200, Chris Hofstaedtler wrote: > I'm wondering if this is really worth doing. Did you have to tell sbuild > about the pbuilder tarball? We tried symlinking the pbuilder tarball into ~/.cache/sbuild, so yes. > If so, then the easier option would be to let sbuild create the tarball, and > not point it to the pbuilder tarball. Yeah. That's what we ended up doing. Helmut
Bug#1109128: sbuild --chroot-mode=unshare fails with Permission denied if the tarball does not contain /
* Helmut Grohne [250711 23:09]: Maybe, we could change https://sources.debian.org/src/sbuild/0.89.3/lib/Sbuild/ChrootUnshare.pm/#L448 to use install -d -m 755 -o 1 -g 1 $rootdir to set up the correct permission in case the tar does not? OTOH, this is basically "free" :-) Chris (cannot reply to my own message yet)
Bug#1109128: sbuild --chroot-mode=unshare fails with Permission denied if the tarball does not contain /
* Helmut Grohne [250711 23:09]: He was reusing a tarball from pbuilder and that tarball lacks an entry for /. I suspect that sbuild creates the root directory for the container with the default umask and never chmods it to 0755. When he created a new tarball with / included, it just worked. Would it be reasonable for sbuild's container runtime to also cover this case? The advantage being here would be an easier transition path for pbuilder users. I'm wondering if this is really worth doing. Did you have to tell sbuild about the pbuilder tarball? If so, then the easier option would be to let sbuild create the tarball, and not point it to the pbuilder tarball. By default it will also recreate the tarball after one week. Chris
Bug#1109128: sbuild --chroot-mode=unshare fails with Permission denied if the tarball does not contain /
Package: sbuild Version: 0.89.3 Severity: minor X-Debbugs-Cc: [email protected] Hi, I helped Samuel set up sbuild with unshare and it didn't just work for him. He got "Permission denied" on executing dpkg. The notable aspect here is that dpkg --print-architecture is the first command not being run as root by sbuild. We eventually noticed the crucial difference: He was reusing a tarball from pbuilder and that tarball lacks an entry for /. I suspect that sbuild creates the root directory for the container with the default umask and never chmods it to 0755. When he created a new tarball with / included, it just worked. Would it be reasonable for sbuild's container runtime to also cover this case? Maybe, we could change https://sources.debian.org/src/sbuild/0.89.3/lib/Sbuild/ChrootUnshare.pm/#L448 to use install -d -m 755 -o 1 -g 1 $rootdir to set up the correct permission in case the tar does not? The advantage being here would be an easier transition path for pbuilder users. Thanks for considering Helmut
