query: mock + libselinux-mock.so LD_PRELOAD... why?

Michael E Brown Michael_E_Brown at dell.com
Fri Dec 7 20:40:44 UTC 2007


On Wed, Dec 05, 2007 at 12:35:46PM +0000, Paul Howarth wrote:
> The way I *think* it used to work was that mock-helper would set the 
> LD_PRELOAD and then exec() the required program (rpm, yum, whatever). 
> When it came to running yum, it didn't exec() yum directly, it exec()-ed 
> mock-yum instead, which was a simple wrapper that removed the LD_PRELOAD 
> from the environment (the libselinux-mock already being in place from 
> the exec() that called it). The result of this was that child processes 
> of mock-yum (e.g. rpm, package scriptlets running in the chroot) got the 
> fake libselinux without the LD_PRELOAD being visible.
> 
> The more integrated architecture of mock now may make this sort of hack 
> quite difficult to implement.

s/difficult/easy/g;

It should be extremely easy to do this, *if* it is necessary. We just
need to set/unset the variable as necessary around all calls to external
programs. Like this: os.environ['LD_PRELOAD'] = "...";  or
del(os.environ["LD_PRELOAD"]);

Luckily, we have *one* entry point to call all external programs, atm,
which is mock.util.do(). We just need to decide before each external
call if we need to set the variable or not.

We also have *one* wrapper for running yum, which then calls down to
mock.util.do(). If necessary, we could easily set/unset this variable in
that call and insulate all other callers from this knowledge.

All-in-all, if we can come up with a test case for why we would still
need the preload, I could quite easily add this functionality back. So
far, though, I'm not seeing a lot of evidence of what is broken, and I'm
the sort that likes to see the broken pieces before I implement the fix.
--
Michael




More information about the Fedora-buildsys-list mailing list