Re: Dilemma using ostree as regular user, losing permission bits

[Colin Walters <walters verbum org>]

On Tue, Jun 6, 2017, at 09:09 AM, Tristan Van Berkom wrote:

> On the other hand, if you want to create a bootable image as a regular
> user, and you want that image to contain a /usr/bin/sudo that is
> setuid, the typical way to do that is:
>
>   1.) Create a sysroot somehow
>
>   2.) Run mkfs.ext4 filesys.img -d ${sysroot}
>
> Now it is conceivable to have userspace utilities to modify permissions
> of files inside an image without mounting it, so we could set the suid
> bit on 'sudo' inside filesys.img, but:

Right, generating filesystem images is basically outside of ostree's
domain.  Yep, AIUI OpenEmbedded uses genext2fs by default for this,
although I think they also experimented with libguestfs?
gnome-continuous uses libguestfs, although that bit is currently
broken for other reasons.

For the Fedora/Project Atomic space in practice we end up using
Anaconda-in-a-VM (via a tool called imagefactory) - and remember
one can create VMs unprivileged.

And then the installer reads content from the host via a temporary webserver,
although with some work we could inject a virtio channel.

>       The guestfish project shows promise, but is immensely complicated
>       to build and then run inside a bubblewrap sandbox (requires qemu,
>       and needs some custom supporting code to define an "appliance").
>
>       This is especially tricky because we are striving for fully
>       deterministic builds, which means any such tooling should be
>       made available to the sandbox, usually by building it, there
>       should never be a host tool dependency for deployments.

Yeah.  I haven't tried libguestfs-in-bwrap...I do use libguestfs inside
some privileged Docker containers though.

Pratically speaking though, it feels to me like requiring libguestfs on
the host shouldn't be too onerous for builders, although you *do* get
into reproducibility issues because of the way it will e.g. use the host
`mkfs.ext4` to make filesystems.

On the other hand, if you want things to be reproducible you'll need
to hardcode mkfs options anyways, right?

>   b.) It would be convoluted, the authors of build metadata would have
>       to express this separately and the suid-ness of things would have
>       to be carried beside the filesystem data itself separately.

The suid state *is* carried inside both "archive" and "bare-user" mode
ostree repos, by design.  It's only when you go to use a "bare" repository
(that could be a libguestfs mount or simply a filesystem in a VM)
that the suid bits are applied.