1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Re: Porterbox - impossible efficient debugging?

    From Andrey Rakhmatullin@21:1/5 to julien.puydt@gmail.com on Tue Aug 13 13:00:01 2024
    On Tue, Aug 13, 2024 at 12:15:22PM +0200, julien.puydt@gmail.com wrote:
    And of course, this is where I came to my wits' end: I can compile the
    new elpi successfully... but I have no way to install this new elpi
    binary packages in the schroot to test it against different coq-elpi!

    Yes, the usual recommendations are "unpack and try pointing to it via
    stuff like LD_LIBRARY_PATH, hopefully such stuff exists for your case".

    Consider using local qemu chroots instead.

    dd-cross-schroot-cmd -s $sessionid -a $targetarch apt-get install ./*foo*_3.14-159_$targetarch.deb

    This still runs random code as root.

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAma7O2stFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh wZsP/RfMDeXHnxu57Q+O7GsOftBTuMi2TGkdwJmMP/GhrdKqRMtj8/KIBkxZg0te B6faJwvp6bYU8vE4qZpDDkrA17w+m/V/vacP9ZZ0WoBgzHrKo+qHfw/68H9XRFus PodCdWcfF9JzumJ44mN5jBpzfd0VSNpSp37BZ8bsegBOApigx1rsGVQwiSl31KkA GCmM3S10SR220USMdsGNzbfZWwxuqyisYpa4K+Easdrv2KKtKGT+uXK6ZPeAyK0+ aEki0VmAY3FD0+HNK3QGn8tFf5kdozNdpCD6vkJDySXoOXUrcustDEaGbsD3YAG3 9zUjL2humYzqsomkROIF43IDsWH9a31Rl2V2z1HeIIYnGzB1EtxXJsd/g7fMtQnn ZOqB8M+IaHZcBhnWmL52OWJRuEIITfz82fwqqPPFMvrULe9Hb2zJpi/Cm5gsVlAB rydNRKJkZ/ZpzHDR3g7gsozALSaIk35tfyyRJmoc1ObUnFvhvFIgppOhqcBQygeS KTY2qsx+L3Ct3bScBvbfef9v6te0L2/W5H3Gr5xy79qBgJ578Ec1HcueaSNR4B/A u7vupvxYHGV/17JX4srkMr6PA4m1Tv+NQReay8tRoJTJ7Tz3FIccHJ6Pgy09/jik UkxZofb7guw0FhU5emouJz/iku4mDGCBepjWEJVwstYzRO68
    =5z4A
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?St=C3=A9phane_Glondu?=@21:1/5 to All on Tue Aug 13 13:10:01 2024
    Hi,

    Le 13/08/2024 à 12:15, julien.puydt@gmail.com a écrit :
    And of course, this is where I came to my wits' end: I can compile the
    new elpi successfully... but I have no way to install this new elpi
    binary packages in the schroot to test it against different coq-elpi!

    This is a situation I've found myself quite often, too.

    BTW, IIUC, it is be possible with namespaces to give root privileges (or
    enough to install packages) to anybody inside a container. [1] could be
    a way, but it needs unprivileged user namespaces. But I understood that
    DSA was reluctant to enable unprivileged user namespaces on Debian
    machines because of security concerns... Couldn't an exception be made
    for porterboxes? After all, these are dedicated to porting and nothing sensitive should be done there.

    [1]
    https://lists.debian.org/msgid-search/20240625081620.GA1354821@subdivi.de

    I'm quite fond of the single-page just-follow-the-steps tutorial:
    https://dsa.debian.org/doc/schroot/
    hence my dream is to be able to do something like the following to get
    not only a cross-compilation but also cross-running through whatever
    virtual system (say provided by a dd-cross-schroot package) :
    [...]

    Actually, you can achieve something similar with qemu-user(-static),
    binfmt and pbuilder:

    sudo pbuilder create --basetgz sid-ppc64el.tgz \
    --distribution sid --debootstrapopts --variant=minbase \
    --architecture ppc64el

    sudo pbuilder login --basetgz sid-ppc64el.tgz

    Of course, that wouldn't be as good as an actual box of the right architecture, but it would definitely help getting many problems
    solved. As you may have noticed from the above I'm quite clueless on
    how schroot and cross-compilation work - and to be honest, I'd like to
    stay so as I have other itches to scratch and hopefully other areas of expertise - but I'm hopeful others have the competence and the will to provide solutions.

    Keep in mind that the solution above remains emulation and I've already
    faced situations where behaviour differed with actual hardware. That
    being said, it helped me a lot in debugging packages on exotic
    architectures.


    Cheers,

    --
    Stéphane

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rakhmatullin@21:1/5 to julien.puydt@gmail.com on Tue Aug 13 13:50:01 2024
    On Tue, Aug 13, 2024 at 01:35:03PM +0200, julien.puydt@gmail.com wrote:
    And of course, this is where I came to my wits' end: I can compile
    the
    new elpi successfully... but I have no way to install this new elpi binary packages in the schroot to test it against different coq-
    elpi!

    Yes, the usual recommendations are "unpack and try pointing to it via
    stuff like LD_LIBRARY_PATH, hopefully such stuff exists for your
    case".

    It doesn't: it's a mix of languages. C, OCaml, elpi and Coq I would
    say.

    Consider using local qemu chroots instead.


    I'd like a one-page easy-to-use tutorial on this.

    It's like normal sbuild but pass --arch=foo to sbuild-createchroot and to sbuild. You'll need qemu-user-static installed.
    That's all IIRC.

    dd-cross-schroot-cmd -s $sessionid -a $targetarch apt-get install ./*foo*_3.14-159_$targetarch.deb

    This still runs random code as root.


    I don't think running random code as root in a virtual environment I'm
    going to delete before the end of the day is a security issue.

    Well, that's the only reason I can think for not being able to run root commands in porterbox chroots directly.

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAma7RfktFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh FmgP/RUAdYYPGogaCGXXSwBihBngYE35p6K5wfP0JzP5SY+QFS+mqmdt5/xYd6HF 7X7+eKzcSb/Rv1z2GqVsV99/cPIpSf+ps9yZdYXXbACMl2UM77Bs1cx78i2qE95I 9QnlXhL6JxKGB6dCFABQPM0p2mA9Dxy9KmaiTSO1K/7rKiEFv2MQ1xk5XnJg/9L7 DBuRp8ws5zt/ihRwq+7mYo33icjsahn7rH4RRltpkaV8f3tHFp9TV2yFeB0jfjyF hlVuN78UpizunUNlqTZqxzg4bJwix/NHb8Dt1uMjEuwSFJC77faE6aQ94VXzPlyY jTjKCXpAPgbxfUIZlr2OdNvro62eQjYxihMH/jVLj3GvEzA/9kimQ/5KmrtWgh28 EpwWqybmYxrgyiTQPuwcigFHfFxrDrQnT/f4Yu9O2dOHtF4Qjl8hGqDKv/8lT9J/ L+xFKdyemOQgYKl88iNkWLuhJxe5iVeYmlE1VYWAX3ljXw2MqaW9I9tQLT0FNkKZ 2HlCEcI3jA0XgkY0eEYIm/AqRLSqbF/jZgLiIN3788YnxDx4f5hzlirAd5nPlgvQ HffNadkWCng9EPvTjbBvCSibDYhLUJ95tG13XVqs5VetpyHXoYjEjH9MqIP0lYB1 F8KBp+aA2B4Sp7fjLgHNMdz7Abz4fLLqqlK1eXvtCQkeMexS
    =Z6Yn
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon McVittie@21:1/5 to All on Tue Aug 13 17:10:01 2024
    On Tue, 13 Aug 2024 at 13:01:45 +0200, Stéphane Glondu wrote:
    BTW, IIUC, it is be possible with namespaces to give root privileges (or enough to install packages) to anybody inside a container. [1] could be a way, but it needs unprivileged user namespaces.

    See also https://salsa.debian.org/debian/grow-your-ideas/-/issues/40
    (sorry, I have not had the time/energy to bring this up with the sysadmin
    team or otherwise promote it).

    unshare and rootless podman have essentially the same requirements:
    they use the same parts of the Linux kernel.

    But I understood that DSA
    was reluctant to enable unprivileged user namespaces on Debian machines because of security concerns... Couldn't an exception be made for porterboxes? After all, these are dedicated to porting and nothing sensitive should be done there.

    The security concern that I'm aware of is mentioned in the issue I linked,
    but it's a trade-off: allowing rootless unshare/podman would make us
    vulnerable to some kernel vulnerabilities that are currently mitigated
    by disabling user namespaces, but conversely, setuid-root things like
    schroot and having chroots containing setuid binaries owned by "real
    root" makes us vulnerable to some attacks that rootless unshare/podman
    would protect us from.

    smcv

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