Re: How do we store/install apps?

[Alexander Larsson <alexl redhat com>]

On fre, 2014-10-10 at 14:51 -0400, Colin Walters wrote:
> On Fri, Oct 10, 2014, at 07:52 AM, Alexander Larsson wrote:
> > For instance, one could have a
> > common repostory with files that have filenames based on (say) the
> > sha1 hash of the content, and then each app could hardlink from
> > those. Or one could have completely separate trees for each app which
> > are only hardlinked when we do an incremental update and keep the old
> > version.
>
> This is precisely what OSTree is (but sha256 of course instead of sha1).
>
> Last time I talked to some other people who were looking at using OSTree
> for apps, I went back and forth on it.  Having apps potentially share
> data with the host OS is nice, and better having apps share data with
> each other.  (Say I'm an app author and I have 2+ apps with a common
> library between them).

I talked to ebassi a bit about what endless does, and they had a lot of
apps that shipped large shared dependencies, so sharing space between
unrelated apps is important to them. This points me to the above model
instead, and I'm actually considering basing the thing on ostree, as it
does exactly this (as you said).

> Although for apps you really don't want to allow them to ship e.g.
> setuid binaries.  An app framework using OSTree as a data format would
> need to disallow that.  And for that matter restrict to uid 0,0, mode
> 0755/0655.

Setuid binaries are not really a problem, because when the apps are
running i bind mount the directories nosuid, so even if it was set it
would not work. What *is* a problem though is the uid, because if you
want to be able to download and store apps in your homedir we can't have
those be owned by root. They have to be owned by the user. So, we have
to somehow rewrite the owner as we pull the repos. Is this doable with
ostree?

> Interesting questions arise too as to SELinux labeling.  You can't
> hardlink unless those are identical.  And probably the OS should be in
> control over the labeling.  Which might imply doing the commit on the
> client side - apps could just come as zip files or something, and they
> get committed then.

SELinux is a bit harder. Ideally you'd want to use selinux mount options
here. Unfortunately selinux labels are only unique per superblock, so
you can't make them different for a bind mount. We have problems with
this in docker too (for btrfs and overlayfs backends). Not sure how to
solve this atm...