Re: Playing around with ostree for apps

[Alexander Larsson <alexl redhat com>]

On tis, 2014-10-14 at 12:14 -0400, Colin Walters wrote:
> On Tue, Oct 14, 2014, at 07:05 AM, Alexander Larsson wrote:
> > So, i updated gnome-sdk (https://github.com/alexlarsson/gnome-sdk/) to
> > use ostree to store and fetch apps.
> >
> > For instance, if you build latest gnome-sdk you can:
> >
> > gnome-sdk-repo add-remote alexl https://people.gnome.org/~alexl/repo/
> > gnome-sdk-repo install-runtime alexl org.gnome.Platform 3.14
> > gnome-sdk-repo install alexl org.gnome.GEdit
> > gnome-sdk-run org.gnome.GEdit gedit
>
> I'm trying to clone this, but the repository needs to be on some HTTP
> server with KeepAlive on at least =)
>
> Can you request access to build.gnome.org?

I'll try to do that.

> > Checking out means hardlinking to the repo, so any files
> > shared between modules is shared (via the hard links) both on disk and
> > in page cache.
>
> But not between users.  Which is going to matter a lot in some
> scenarios.
>
> I think I agree with Lennart here in that the default architecture
> should use polkit and talk to the system.  That doesn't mean that we
> couldn't also support per-user apps.

I don't disagree. I think the primary form of installation should be in
a machine-wide system directory by some service. However, we should not
make the "install as user" usecase impossible.

> Things get really interesting of course if we're really thinking about
> production because

because?

> > There are some issues:
> >
> > * We don't clean up old versions on update yet
>
> ostree prune --repo=repo --refs-only --depth=0
>
> is what "ostree admin upgrade" uses.

Its not only that, it doesn't even remove the previously checked out
tree. Its just a TODO, nothing really problematic.

> > * Ownership of files is problematic. 
>
> This issue goes away if apps are stored as branches in the system repo. 
> On the other hand - again stuff like setuid.  You said you filter them
> while running, but I'm not sure that's good enough; I'd say we really
> don't want potential privilege escalation binaries lying around at all.

I agree, we don't want to have setuid binaries lying around, even in the
repo. Can we have files in the repo not store the setuid bit? That would
mean we have to copy the file (not hardlink) when checking out, but how
many files are setuid? Then we could have a no-setuid checkout mode
similar to -U that does not apply this flag at all.