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

Paul Howarth paul at city-fan.org
Thu Dec 13 12:01:47 UTC 2007


Paul Howarth wrote:
> Michael E Brown wrote:
>> On Fri, Dec 07, 2007 at 02:40:44PM -0600, Michael E Brown wrote:
>>> 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.
>>
>> Paul,
>>     I have recreated the git selinux branch at
>> http://linux.dell.com/git/mock.git (if you have previously cloned,
>> please re-clone.) It is based on the current 0.8 codebase.
> 
> OK, I'll give that a go as soon as I can find a reasonable amount of time.

Just tried it, seems to have the same LIBDIR problem as last time:

$ mock -r fedora-8-x86_64 rebuild mock-0.8.17-0.se.fc8.src.rpm
INFO: mock.py version 0.8.17 starting...
State Changed: init plugins
State Changed: start
ERROR: global name 'LIBDIR' is not defined
Traceback (most recent call last):
   File "/usr/libexec/mock.py", line 529, in <module>
     main(retParams)
   File "/usr/libexec/mock.py", line 512, in main
     do_rebuild(config_opts, chroot, args)
   File "<peak.util.decorators.rewrap wrapping __main__.do_rebuild at 
0x008BA668>", line 3, in do_rebuild
     def do_rebuild(config_opts, chroot, srpms): return 
__decorated(config_opts, chroot, srpms)
   File "/usr/lib/python2.5/site-packages/mock/trace_decorator.py", line 
70, in trace
     result = func(*args, **kw)
   File "/usr/libexec/mock.py", line 312, in do_rebuild
     os.environ["LD_PRELOAD"] = LIBDIR+"/libselinux-mock.so"
NameError: global name 'LIBDIR' is not defined

Having fixed that, I found that some packages I tried built OK but there 
were still lots of messages about the LD_PRELOAD in the root and build 
logs. The visibility of LD_PRELOAD in the build phase caused builds of 
proftpd to fail on f8.x86_64 with a linker error (complaint about a 
relocation).

So I added:

    del(os.environ["LD_PRELOAD"])

between the calls to chroot.init() and chroot.build() in do_rebuild, and 
that fixed that problem (there are still the messages in the root logs 
though.

The resulting target root directories now contain a mix of var_lib_t and 
rpm_var_lib_t files, and apparently nothing else. That should fix pretty 
well all of the selinux denials now.

I still need to contrive an example of a package that needs the mock 
selinux policy module from the wiki page; I'll keep trying.

Paul.




More information about the Fedora-buildsys-list mailing list