Re: App image experiments

[Alexander Larsson <alexl redhat com>]

> On Mon, 2013-03-18 at 14:22 +0100, Alexander Larsson wrote:
> > > On Mon, 2013-02-25 at 17:18 +0100, Alexander Larsson wrote:
> > >
> > > >  ./run-merged /opt/base_os/F18 ./nautilus.squashfs
> > >
> > > What is the point of constructing the F18 chroot versus just using / ?
> >
> > The whole point of the new app proposal is to run each app in a
> > different runtime environment than the full OS. Each app declares what
> > highlevel requirements it has (bare, gnome-os-1.0, etc) and then it will
> > *only* see that. 
>
> Well...yes, I can see that as a goal for running on top of distributions
> as they exist today.  We don't really need it for applications on top of
> gnome-ostree or the like though.

I don't see why not? This is a major part of the new application system
proposal. Even with a ostree based distro I think it makes sense to hand
over a limited runtime to the app rather than "whatever happens to be in
the ostree system". Its clearly needed for the heavily sandboxed app
case, but its also nice for "old school applications". Did you read
lennarts proposal?

> But there are two major API entry points for applications:
> 1) Shared libraries
> 2) /usr/bin
>
> You're solving #2 but not #1.  Solving #1 is actually quite hard, but
> it's equally important.  The traditional approach for #1 is not having
> the headers and .so link ("-devel package") in the buildroot.  Certainly
> on the gnome-ostree side that'd quite possible to do.

I'm not quite sure what you mean here. Any app that specifies that it
requires a profile like "base-os" will see a system that only includes a
libc (of some specified ABI version) and a few other really core libs,
and its up to the app to bundle whatever else it needs itself. Its up to
the application authors to compile and bundle the extra libs however
they want, and its up to the maintainers of the base-os profile to
maintain it in an ABI compat way. Similarly, the gnome project needs to
define a gnome-os-1.0 profile containing only things we see as
supportable in an ABI compat way going forward.

> > Thats not really what i mean though. When a user mounts a loopback
> > filesystem the kernel fs code is running, and any change to the file
> > will be done behind the filesystems back. Obviously any data in the page
> > cache will be kept up to date since modifications to the file is done
> > through the kernel, but any other cache on the filesystem level will not
> > see such changes. So, say cached inode info in the kernel may not
> > anymore correspond to what is on disk. Isn't there a risk for exploits
> > and whatnot here?
>
> Oh true, that's even more of a risk than hostile disk images.  At least
> with those we could verify it statically before fully mounting it
> read/write.

This is even more risky now that non-root can mount loopback mounts via
user namespaces.

> But this opens the question - should the OS allow the application data
> to be writable at all (even if installed per-user)?  I'd tend to say no.
> Clearly if we give applications a writable space they can use it to do
> their own custom updater schemes by downloading new code there and
> executing it (easy to get around noexec mounts with an interpreter),
> but it seems like something we should really try to discourage.

Any real world system needs to allow apps to sideload extra data, for
instance most games download new levels and whatnot. However, that
should not be done by modifying the original app image, but rather by
giving the app some FS space that we assign to the app.