On Sun, 2007-12-02 at 15:51 -0500, Colin Walters wrote: > On Sun, 2007-12-02 at 15:39 -0500, David Zeuthen wrote: > > On Sun, 2007-12-02 at 14:37 -0500, Colin Walters wrote: > > > And more generally, to have one VM per language type, rather than per > > > app. > > > > There's a lot of security models that break down if everything is tied > > to a single process. > > I'm not sure why people are going from "Unify a few Python programs into > one VM" into "We must only have 3 processes total!". > > If some application was security sensitive, we could keep it separate.
That's a fine goal but not really how I (and apparently others) read your original message. (FWIW, personally, I'd like to see all of our service daemons (g-p-m, g-v-m, pk-update-client, etc.) all sharing the same process space. Things like that.) > But fundamentally right now the desktop is still one security domain, > and I don't see that changing in the near future. http://lists.freedesktop.org/archives/xorg/2007-November/030631.html That said, it's probably a few years out before things like password dialogs a) cannot be poked by e.g. the browser; b) can be poked by the a11y tools. Bunch of other use cases too (browser, email in confined domains). But it's something that is badly needed and XACE-SELinux brings us one step closer. > > Not to mention a bunch of other problems. It's > > probably better to just fix the VM's. > > Far harder - and I think it would likely require language semantics to > change, in particular for Python. > > Having one VM for Python applets would not be rocket science. Someone > just needs to spend the few days on it, and get patches to use it > upstreamed. Sure, but keep in mind what you're suggesting is a stop-gap fix that will hide the real problems (per-process overhead), introduce weird and hard to fix bugs. You know what happens to stop-gap fixes? They become mainstream and people will never fix the real problem... Funny enough, it's also sometimes easier to fix root problems than to introduce a bunch of stop-gap fixes. David _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
