Hello all, Jamie Strandboge [2015-02-25 11:43 -0600]: > However, reusing executables from an existing deb is almost > certainly going to break often because those executables are running > under the app's confinement that was not designed for them.
That's what the overlays are meant to fix: Of course a snap which slurps in a deb couldn't access the OS' files; but these would have their own "personal" /etc/, /usr/share/foo/ etc. overlay which they can do whatever they want with -- we don't confine the app from accessing its own data, after all. > Furthermore for statically compiled apps, LD_PRELOAD would be set on > statically compiled app launch, but the app wouldn't propagate the > LD_PRELOAD for a fork/exec of something within the app area that is > dynamically linked. Why not? AFAIK this only applies to binaries which are set[ug]id, so reusing those from debs is indeed not possible with the preload approach; but that would not be a very common case? Non-[sg]uid binaries inherit their environment. We can/should certainly not hope to make *all* debs work that way, but our goal is to make the interesting/useful ones work: libraries, JavaScript, Python, and other language interpreters, databases, web servers, etc. IOW, all the standard technologies that apps built on, to avoid pushing the maintenance of these standard technologies to app authors (which neither them nor us want). > So, unless I am missing something, reusing debs seems really to cater to > dynamically linked apps to reuse libraries and data files. Certainly that, but perhaps even more importantly, talk to the "imported deb" services through sockets (databases), or the command line (invoking an interpreter)? > > My alternative to overlayfs at the time was a bind-mount farm in a > > separate mount namespace, that is, giving the exact same fs view as > > you'd get using read-only overlayfs but using read-only bind-mounts and > > tmpfs mounts instead (possibly hundreds/thousands of them). > > > While I don't doubt we could make this work, this doesn't feel snappy to me TBH, LD_PRELOAD feels even worse to me. It's a hack which only sometimes works and sometimes not, it's veeeeery brittle (did you ever try to use fakechroot? it's a very "entertaining" exercise and constantly needs to be updated to newer glibc versions and architectures). I think the bind mount farm is a lot better and more robust already; if we can't get a proper kernel VFS based solution (aufs/overlayfs) then this seems worth a shot at least? Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
-- snappy-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
