On 4/22/23 10:13, David Michael wrote: > On Fri, Apr 21, 2023 at 10:02 PM Demi Marie Obenour > <demiobenour@xxxxxxxxx> wrote: >> On 4/21/23 11:13, David Michael wrote: >>> Hi, >>> >>> Following up on this, Firecracker has been accepted and submitted to >>> Fedora. Thanks to Fabio for all of the Rust reviews. >>> >>> F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-dca8124d3b >>> F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-edcbcf18e0 >>> >>> Some quick comments on the TODO from the original e-mail: >>> >>> On Sat, Mar 4, 2023 at 12:40 PM David Michael <fedora.dm0@xxxxxxxxx> wrote: >>>> - The musl package adds /usr paths for compatibility with the compiler --sysroot option. >>>> - The rust compiler adds musl target subpackages. >>> >>> Targeting musl was dropped after the initial discussion, so there is >>> no sandbox or seccomp filter in Fedora until that can be implemented >>> with dynamic linking glibc upstream. I'll keep the Copr repo[0] >>> active for a while to provide musl builds. >> >> Would it be possible to add a warning to this effect? Without any form >> of sandboxing Firecracker is not suitable for production use. > > Where would such a warning be placed? The sandboxing is done by a > standalone program[0] which is not built in the package, so it should > be clear that it isn't available. Package description perhaps? >> Does the >> sandboxed portion of Firecracker do anything that would require an NSS >> (name service switch) lookup, such as DNS or username resolution? > > I don't think NSS lookups are an issue since the program takes > numerical UID/GID values as command-line arguments. The main breaking > issue with the jailer is that it requires Firecracker to be a single > static binary[1] (which is the musl target's default output upstream). > Their documentation also says glibc isn't supported, but I haven't > tried making a static glibc binary to see what fails. The seccomp > filter being unimplemented for glibc is a separate issue from the > jailer. glibc does not support static linking well. >> If >> not, then I don’t see why musl (which Fedora already ships!) would be a >> problem. > > There is no problem technically; the Copr repo[2] is building > Firecracker RPMs with musl. Maintainers of both Rust and musl seemed > to be against it in Fedora. From this thread: Why does Fedora not want to ship Firecracker statically linked to musl? That is the supported and tested configuration upstream. Using glibc or dynamic linking is not supported for production use. -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
