LD_PRELOAD work in progress

[Jamie Strandboge]

On 02/24/2015 04:40 PM, Jamie Strandboge wrote:
> On 02/24/2015 03:29 PM, Michael Terry wrote:
>> Hello!  So I worked on a proof-of-concept for faking an overlayfs scenario by
>> doing path-redirection in an LD_PRELOAD library.
>>
>> I've got working code here: lp:~mterry/+junk/snappy-preload
>>
> This is a very intriguing idea.
> 
> Making debs from the archive reusable in snaps easily is a really great goal.
> The suggested overlayfs approach in my mind has two major drawbacks though: 1)
> backporting overlayfs to earlier kernels is hard and not porting-friendly and 2)
> there is a difficult disconnected path issue with apparmor with the current
> implementation[1]. In addition to those, I've been quite concerned about the
> complexity that adding overlayfs mounts brings to the snappy user and developer
> experience. This LD_PRELOAD idea removes the two major drawbacks and IMO makes
> for the possibility of a better experience.
> 
> The security team is tasked with looking at the viability of overlayfs wrt the
> apparmor issue[1] (there is some promising upstream work happening that may
> help) and we will add examining this LD_PRELOAD approach.
> 
> I'm very curious what others have to say.
> 

Actually, I have a question:

Currently the thinking is that an app may declare its dependency on 0 or more
frameworks and may also itself declare its own overlay, with the overlayfs idea,
the launcher will mount the frameworks in order on top of each other, with the
app overlay on top of that, then exec the program.

It seems like we could achieve this with the LD_PRELOAD idea by requiring the
frameworks to each ship a preloadable library, then the launcher builds up the
LD_PRELOAD list appropriately before launching the app. This could be made to
work, but I wonder if we think hard about multiple frameworks and an app overlay
with LD_PRELOAD in mind, if there is a simpler way.

Michael, had you considered the above use case when investigating your idea?

-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150224/4c30dcf4/attachment.pgp>