LD_PRELOAD work in progress

Michael Terry michael.terry at canonical.com
Mon Mar 2 15:07:52 UTC 2015

Sorry, I've been distracted by unity8 work and holiday, but I'm coming back
to this thread.

So my original goal was to easily (and in shortish time frame) use archive
debs in a very fat (non-phone) snap.  Seems there are several possible ways
to do that (this list is collated from this thread, looking largely at
features instead of maintenance or security complexity):

Overlayfs (currently blessed approach):
- Won't work on android kernels without significant backport work on our end

- Is hairy to get right for all cases (many obscure low-level entry points
that take a filename, pitti warns there are gaps)
- App might make a direct ioctl calls that can't be intercepted
- Can't work for programs that statically-link glibc (which isn't so bad
because those aren't likely to want to pull in other debs)
- Won't work for set[ug]id programs (which isn't a problem for snappy use
cases right now, I believe)

- (out of my historical depth) Old competitor of overlayfs that we could
resurrect in cases that overlayfs can't work, so there would be some
maintenance work on our end to make this deprecated technology work again

Bind-mount farm:
- Resource heavy

- Terrible performance

(And a special mention that none of the above solutions are drop-in ready
for snaps yet.  And they all seem to need a script which actually does the
slurping of debs into their own file tree at snap-build-time.  That script
doesn't exist yet, right?)

So, pitti's warnings of doom around LD_PRELOAD are giving me strong pause.
But LD_PRELOAD may still be useful for some use cases that don't require
weird low-level debs that might hit the functionality gaps.  Especially
since it is self-contained and opt-in.  It can just be a tool some people
might want to use, as long as they understand the caveats.

In my specific use case (which is a fat snap with the entire stack of debs
between Ubuntu Core and unity8), I bet I will hit some of pitti's gaps.
Maybe what I want is a container solution like LXC to have a self-contained
system inside of the snap, at the cost of duplicating the Ubuntu Core layer.

(Though, how close are we to having overlayfs support ready to use for


On Thu, Feb 26, 2015 at 2:01 PM, Jamie Strandboge <jamie at canonical.com>

> On 02/26/2015 12:31 PM, Steve Langasek wrote:
> > On Wed, Feb 25, 2015 at 11:43:44AM -0600, Jamie Strandboge wrote:
> >> So, thinking about what overlayfs is trying to solve more-- there are
> really
> >> three things that could be in the overlay area:
> >>  * libraries
> >>  * executables
> >>  * data files
> >
> >> There are essentially two things that we've thus far been thinking
> about that
> >> may use overlays:
> >>  * apps that reuse existing debs
> >>  * frameworks
> >
> > This formulation seems to suggest that frameworks would not reuse
> existing
> > debs.  But we have at least one case where we're trying to enable exactly
> > that, namely comfy.  How does that map to your model?
> >
> I didn't mean to suggest that per se, but I've always thought of comfy as
> something different: eg, a way to extend the system with useful tools but
> that
> other snaps wouldn't depend on. Certainly this is delivered as a snap, but
> I'm
> not sure if this is a normal snap with unconfined security policy for each
> binary or a special snap with no security policy attached to it.
> We've defined frameworks (and yes, I realize this hasn't hit the public
> list
> yet-- that is something I need to pick up) as: "frameworks exist primarily
> to
> provide mediation of shared resources (eg, ports, device files, sensors,
> cameras, etc)" and "frameworks are tightly coupled with separately
> maintained
> security policies that extend the security policy available to apps
> consuming a
> framework". This doesn't work with comfy-- eg, if comfy provides vim, and
> vim
> requires rw to everything on the system, and vim allows scripting, and a
> snap is
> allowed to use vim under vim's policy, then the snap can break out of
> confinement.
> But to your point about (non-comfy) frameworks, because frameworks need to
> be
> defined so specially, I imagine in practice they wouldn't use a lot of
> existing
> debs, but I don't see why they couldn't if they really wanted to.
> --
> Jamie Strandboge                 http://www.ubuntu.com/
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snappy-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150302/9906e705/attachment.html>

More information about the snappy-devel mailing list