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

[Will Manley <ostree williammanley net>]

On Tue, 6 Jun 2017, at 14:09, Tristan Van Berkom wrote:
> On Tue, 2017-06-06 at 16:02 +0900, Tristan Van Berkom wrote:
> [...]
>
> Actually let me follow up on this because this really gets to the root
> of the issue I think:
>
> > > The rationale for clearing suid bits is that you *really* don't want to
> > > create suid binaries owned by your build user - any
> > > other user on the system could execute them to gain *your* uid's
> > > privileges.
> > >
> > > Another way to say this is that bare-user is designed for *container*
> > > use cases, and builds should always be in a container that runs
> > > as non-root.  And IMO, you shouldn't use suid binaries in containers.
> > > There's absolutely no use case for having e.g. a suid `/usr/bin/sudo`
> > > in your build containers.  Nor for any of the PAM binaries, etc.
>
> So yes, having a setuid 'sudo' belonging to you, means that any other
> user on your machine could potentially gain your privileges through it;
> creating a setuid 'sudo' in your home account somewhere is certainly
> not recommendable.
>
> 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}

It sounds like you're doing something in your build system in some ways
similar to us.  We run our builds as a normal user with an ostree repo
in bare-user mode.  

A build step typically consists of:

1. Do ostree checkout of rootfs to modify with `--user-mode` and
`--require-hardlinks` for speed
2. Use `bwrap` to chroot into this checkout and run the code
3. Check the result back in with --link-checkout-speedup

To maintain permissions over this process we've get a modified version
of fakeroot[1] that understands ostree's xattr metadata.  It's not
perfect but it works well enough for us.  We do a bunch of apt-get
installs in this way and the permissions come out right.  For your case
you should be able to do a checkout and then run `fakeroot mkfs.ext4`.

We also have a modified version of bwrap with overlayfs support[2] to
make step 2 not modify the hardlinked files.  This was not accepted
upstream[3] (for good reason)  but it works for us.

[1]: https://github.com/stb-tester/fakeroot/tree/ostree
[2]: https://github.com/stb-tester/bubblewrap/tree/overlay
[3]: https://github.com/projectatomic/bubblewrap/pull/167

Thanks

Will