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

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

On Thu, 2017-06-08 at 21:19 +0100, Will Manley wrote:
> 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`.

Hi,

Yes sounds similar, we like ostree for storage, and bwrap for
sandboxing, but we never want to access ostree from inside the sandbox
because that would mean leaking the host into the build environment.

Similarly, we never want to run mkfs or anything which mutates built
data because that violates the no host tool policy.

I'll take a look at your special fakeroot as I suspect it might save me
some time using ostree API :)

That said, I will be experimenting with the idea of pseudo-backed-by-
ostree as I mentioned in my last email. Except I am thinking of
implementing it as a fuse layer.

Actually I'm currently working on a fuse layer which provides a "copy
on write" hardlink experience; this is only for cases where the build
system needs to run what we're calling "system integration" commands
(i.e. things like package post-inst scriplets and the like, to update
system caches and such). The build directories themselves are checkouts
from git or unpacked tarballs so they need not suffer any performance
hit from fuse-over-python (I think this fuse layer sounds similar to
your custom overlayfs).

What I am thinking for spoofing permissions is basically:

  o At ostree checkout time, we also fetch all the real permissions
    and load them into a separate store (maybe SQLite like psuedo does)

  o The fuse layer, at mount time of this checkout, interfaces with the
    same permissions/attributes store, storing only what the user has
    permission for in the real filesystem.

  o At unmount time of the fuse layer, we extract the new state of this
    store, and use that to implement the commit modifiers for ostree
    commits.

A short read through the libguestfs bug which Colin mentioned:
   https://bugzilla.redhat.com/show_bug.cgi?id=1060423

Shows me that I *might* run into some trouble with SELinux and fuse,
but libguestfs is a much more complex beast with virtualization of it's
own, so I am hoping that that case does not apply to us.

Cheers,
    -Tristan