Re: App image experiments

[Colin Walters <walters verbum org>]

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.

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.

(But then this raises the question of what exactly is in the "SDK" and
for how long do we maintain it etc.)

>  and your bundled libs
> will not conflict with system installed ones.

Right, we don't want applications to be able to see each other's data.
But doing / instead of a chroot won't affect this either way.

> This is what i mean by "put it in a different prefix". I.e. you'd build
> your app in the bundle with a prefix other than /usr, which should let
> you compile the schemas at *image build* time. This will of course also
> let us use the system compiled schemas for OS stuff rather than
> duplicating it.

Ok, yes.

> 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.

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.

If the application launcher is just a random setuid binary, then that's
harder to do, so maybe this is an argument more for a dbus service.