Re: App image experiments

[Alexander Larsson <alexl redhat com>]

> 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. This separation means you will not accidentaly pull in
dependencies that are not supposed to be there and your bundled libs
will not conflict with system installed ones.

> > The second one is harder. It fails because glib-compile-schemas has
> not
> > run in the merged /usr/share/glib-2.0/schemas where the nautilus rpm
> put
> > it. We need to run the schema compilation and things like that
> during
> > image construction, and probably put it in a different prefix.
> >
> > Basically, this is where we need to solve the "search path problem".
>
> I think we need something different than that - if I was a system
> administrator, I'd like to be able to manipulate and script the
> settings
> for all installed apps.  But that shouldn't involve running them.
>
> So it doesn't make sense to me that each application would have a
> compiled schema blob that includes OS + that app.  Rather apps would
> have a compiled schema for just their app, and tools like gsettings
> would be aware of how to merge in the application data dynamically by
> modifying their search path to include the exported schemas.

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.

> > Also, I worry a bit about the loopback mounted files. There is
> nothing
> > prohibiting the user to modify the fs images while the app is
> running,
> > is there? 
>
> chmod o-w ?

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?