LD_PRELOAD work in progress

[Martin Pitt]

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150226/67672e6f/attachment.pgp>