1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1109128: sbuild --chroot-mode=unshare fails with Permission denied

    From Helmut Grohne@21:1/5 to All on Fri Jul 11 23:10:02 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Hofstaedtler@21:1/5 to All on Fri Jul 11 23:20:01 2025
    * Helmut Grohne <[email protected]> [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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Hofstaedtler@21:1/5 to All on Fri Jul 11 23:30:01 2025
    * Helmut Grohne <[email protected]> [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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helmut Grohne@21:1/5 to Chris Hofstaedtler on Fri Jul 11 23:40:01 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Fri Jul 11 23:50:01 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Tue Jul 15 11:40:01 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Tue Jul 15 12:00:01 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)