Request for classic confinement: distrobuilder

store-requests
#1

Hey there,

The LXD team develops an image building tool called distrobuilder which we use to produce all our images:

It’s a pretty straightforward Go application that we very easily managed to snap.

I however don’t think we can have it be strictly confined as it needs to:

  • Download artifacts for just about any Linux distribution (not an issue)
  • Extract those artifacts
    • tarballs (not an issue)
    • squashfs (not an issue)
    • iso images (needs loop devices and mounting of filesystems)
    • squashfs in iso (similar to iso but extra mounts)
    • docker images (problematic)
  • Setup a minimal container using pidns and mntns (problematic)
  • Use chroot/pivot_root (problematic)
  • Run arbitrary commands inside that chroot (package installations, customization scripts, …) (problematic)
  • Create arbitrary devices nodes (char & block) (problematic)
  • Compress the resulting tree (not an issue)

Our long term goal for security is to be able to operate distrobuilder inside an unprivileged LXD container, though even there we still have quite a few issues, especially around mounting iso, squashfs, ext4 filesystems. We can do some of that through FUSE, but once we’re dealing with code coming from the distro we’re building, it gets harder to go and alter their code to use FUSE rather than a straight mount.

#2

Given the usage requirements for distrobuilder I am :+1:

#3

Would be great to consider an interface for creating/managing block nodes, and setting up containers as described, but until we have those, and with vetting done, +1 from me.

#4

What needs to happen next? Looks like we got +1 above but there’s no store hint in place yet that I can tell, need anyone else to review before @jdstrand or someone from store can action?

#5

@stgraber you need to wait :slight_smile: Process for aliases, auto-connections and tracks. “Voting period is one week” and votes are tallied after that period is elapsed.

Btw, +1 from me as well ; your requirements make sense for use of classic in a build tool which is expected to have access to a many aspects of the system as you very clearly described. My only comment would be that maybe you don’t need classic for unpacking iso images; in the old checkbox project we obviated the need for root permissions by using isoinfo (from genisoimage package) to extract some or all files from an iso image. But it needs some extra elbow grease; if you’ll get classic anyway, doing so via a mount might be easier.

  • Daniel
#6

Note, classic requirements gathering and vetting does not require a vote or a waiting period.

As per previous responses, the requirements are understood and the publisher vetting. Granting use of classic. This is now live. Your next upload should pass automated review.

Also, thank you for the clear and detailed request.

1 Like