On Thu, 2014-01-02 at 15:22 +0000, Michael Ikey Doherty wrote: > * We remount "/" read-only in a bind-mount
[and put application files in a private directory] There's a lot to be discussed about application data storage. Right now you have all sandboxed applications sharing a single store - easily fixed, but worth noting. The real problem though is that we don't want to toss out unified manageability. For example, dconf (via GSettings) allows system administrators to lock down configuration. With your sandbox as it is today, the schemas won't be put in a place where the admin can see them. (Or for that matter, running "gsettings" from a regular user terminal won't be able to either). This is where large parts of the stack (dconf, gnome-keyring, etc.) need to be aware of and integrate with the application installation/management tooling. It can't just be a random setuid binary. > The isandbox binary is setuid to root, ...like many other projects out there such as glick2. But I don't think this is right - applications should be launched via a (DBus) service. Say we have systemd-for-the-session, then systemd could take care of launching apps and setting up the environment. setuid binaries are a large attack surface. > In order to access files it must talk via > dbus to the "PortalManager". While my implementation is unfinished right > now, this essentially is used now to open a GtkFileChooserDialog over > dbus. This is the real core of the issue; how the portals are integrated with GTK+ and the rest of the stack. > An SDK really needs to be developed. Developers need a way to target an > existing platform version (3.10, 3.12, etc) and distribute their project > for that version. It seems to make sense to extend from the Eclipse RCP, > as other projects have done (i.e. ADT). Hah. I would certainly agree that the Eclipse ecosystem has developed a lot of useful technology around versioning, plugins, deployment etc. That said, RCP is kind of a large lump to swallow for say gnome-clocks =) The "platform versions" have existed for quite a while implicitly in the versions of GTK+ and GLib etc. that are used for a particular release. But practically speaking I think we will need something a bit more flexible than that. With my Red Hat Enterprise Linux hat on: we do a lot of backporting, and that results in version skew. > A decision needs to be made by GNOME on the real primary development > language employed by new applications. I disagree; applications should either be speaking to GTK+ as they do now (directly for C/Vala apps, via gobject-introspection for bindings), or DBus. > Relevant WIP repository: https://github.com/ikeydoherty/app-concepts Thanks for working on this! I think a useful milestone to target would be sandboxing applications that need no additional permissions. For example, gnome-calculator. A comparison to other projects out there (Ubuntu Click, zeroinstall, etc.) would be useful. _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
