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

[Colin Walters <walters verbum org>]

On Mon, Jun 5, 2017, at 05:49 AM, Tristan Van Berkom wrote:

> When a file is initially checked in to a bare user repository, the
> ownership, permissions and xattrs are stored separately so they can be
> checked out without any data loss by the root user (when _not_ using
> the user mode checkout option).

s/by the root user// - A quite important semantic is that one can do a
pull from bare-user to one of the other two modes (`archive` or `bare`)
without data loss.  It's not just about checkouts.

Today e.g. gnome-continuous uses the "uncompressed objects cache"
code which I want to delete in favor of bare-user.  Basically we do
checkouts and commits into a bare-user repo, and only then "export"
it to archive.

This way, you only pay the cost of doing zlib-compression when exporting
complete trees, rather than for each build artifact.

> Using bare repositories works fine for both requirements (A) and (B),
> assuming that the same user is committing and checking out files, but
> then will fail for requirement (C), as far as I can see things will
> break down as soon as a user on another computer attempts to checkout
> from a cloned repository (in the case that their local uid differs from
> the original committing user's uid).

I'll be honest, I have never had anything like requirement (C) in mind.
What specific technology is in use here?  NFS?  sshfs?

I don't understand how it would work, since one can't create a hardlink
to file one doesn't own.

Maybe you want something more like a NFS mount that acts as a read-only
mirror, and then each client has a bare-user mirror?  I did *kind of* have
something like this in mind with the "parent repo" code that is in libostree
today, except it's more about reading, we won't do "copy down" automatically
if you want to hardlink.

We could indeed add some logic to libostree to enhance this use case.
But I'd like to know a bit more about the specific approach you're using.

> What is the rationale behind forcing 0755 on all regular files in user
> mode repos and clearing of setuid/setgid bits in user mode checkouts ?
> (what software depends on this lossy behavior, and why ?)

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.

(bubblewrap basically enforces this by using PR_SET_NO_NEW_PRIVS)

As far as 755...hmm, I am not sure why we're doing that.  Is this
an aesthetic concern that every file is executable?   

> Perhaps it would be more interesting to use "bare" repo mode for
> regular users, but provide an option for overriding the uid/gid of
> every file at ostree pull time ? This way a central repository could
> store files as uid/gid 0, but regular users could pull to their own
> mirrors while overriding the uid/gid in their local clones ?

You can do that today with "central repository" being an "archive"
repository accessible via HTTP, and users pull down to "bare-user"
repos right?