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

Paul Howarth paul at city-fan.org
Mon Dec 3 16:49:41 UTC 2007


Michael E Brown wrote:
> On Fri, Nov 30, 2007 at 04:17:52PM +0000, Paul Howarth wrote:
>> Michael E Brown wrote:
>>>    I need a little bit of help understanding what the
>>> 'libselinux-mock.so' LD_PRELOAD was supposed to be doing. I released and
>>> pushed out mock-0.8 without this. I have rebuilt most of rawhide with
>>> this new mock version and have not seen anything that I directly can say
>>> was a failure due to this being missing, so I am sort of not seeing the
>>> point.
>>>
>>>    I have searched around as much as I can to try to understand why
>>> this was put into place. From what I can understand, it was only put in
>>> in the FC2 timeframe to fix some problems with the selinux policy on the
>>> host machine. These *appear* to have been fixed in the host selinux
>>> policy, so again, i dont see a reason to keep this around.
>>>
>>>    Jesse mentioned on IRC, though, that this might be needed, so I pose
>>> this question. I've a local branch set up with the 0.8.x code and the
>>> LD_PRELOAD put back in. So, I can quickly spin a new release with this
>>> back in if it is actually needed. So far, I havent convinced myself it
>>> is needed, though...
>>>
>>>    Could somebody please enlighten me?
>> I suspect it was there to convince rpm that selinux was disabled and 
>> hence prevent it from trying to set the contexts of installed files. If 
>> rpm doesn't set the context, the files are installed as mock_var_lib_t 
>> (assuming my policy module from the wiki is loaded), and this is a 
>> "neutral" type that doesn't cause any problems. However, if rpm sets the 
>> contexts of files it installs, it'll set things like /sbin/ldconfig to 
>> ldconfig_exec_t, and there is now a transition defined in policy from 
>> unconfined_t to ldconfig_exec_t. The result of this is that some 
>> processes such as ldconfig get run "confined" in the chroot and fail as 
>> a result because not *all* file contexts are set up as they would be on 
>> the host system, which is what the policy is set up for.
>>
>> I've not quite figured out all te ins and outs of it but a tell-tale 
>> sign of there being a problem is to look (ls -lZ) at the root 
>> directories of your chroots and see if they look like this:
>>
>> /var/lib/mock/fedora-2-i386-core/root:
>> drwxr-xr-x  root root system_u:object_r:bin_t:s0       bin
>> drwxr-xr-x  root root system_u:object_r:boot_t:s0      boot
>> drwx------  root mock system_u:object_r:mock_var_lib_t:s0 builddir
>> drwxrwsr-x  root mock system_u:object_r:mock_var_lib_t:s0 dev
>> drwxr-xr-x  root root system_u:object_r:etc_t:s0       etc
>> drwxr-xr-x  root root system_u:object_r:home_root_t:s0 home
>> drwxr-xr-x  root root system_u:object_r:root_t:s0      initrd
>> drwxr-xr-x  root root system_u:object_r:lib_t:s0       lib
>> drwxr-xr-x  root root system_u:object_r:mnt_t:s0       mnt
>> drwxr-xr-x  root root system_u:object_r:usr_t:s0       opt
>> drwxrwsr-x  root mock system_u:object_r:mock_var_lib_t:s0 proc
>> drwxr-x---  root root system_u:object_r:user_home_dir_t:s0 root
>> drwxr-xr-x  root root system_u:object_r:bin_t:s0       sbin
>> drwxr-xr-x  root root system_u:object_r:mock_var_lib_t:s0 selinux
>> drwxrwsr-x  root mock system_u:object_r:mock_var_lib_t:s0 sys
>> drwxrwxrwt  root root system_u:object_r:tmp_t:s0       tmp
>> drwxr-xr-x  root root system_u:object_r:usr_t:s0       usr
>> drwxr-xr-x  root root system_u:object_r:var_t:s0       var
>>
>> rather than this:
>> /var/lib/mock/fedora-3-i386-core/root:
>> drwxr-xr-x  root root system_u:object_r:mock_var_lib_t:s0 bin
>> drwxr-xr-x  root root system_u:object_r:mock_var_lib_t:s0 boot
>> drwx------  paul mock system_u:object_r:mock_var_lib_t:s0 builddir
>> drwxrwsr-x  root mock system_u:object_r:mock_var_lib_t:s0 dev
>> drwxr-xr-x  root root system_u:object_r:mock_var_lib_t:s0 etc
>> drwxr-xr-x  root root system_u:object_r:mock_var_lib_t:s0 home
>> drwxr-xr-x  root root system_u:object_r:mock_var_lib_t:s0 initrd
>> drwxr-xr-x  root root system_u:object_r:mock_var_lib_t:s0 lib
>> drwxr-xr-x  root root system_u:object_r:mock_var_lib_t:s0 media
>> drwxr-xr-x  root root system_u:object_r:mock_var_lib_t:s0 mnt
>> drwxr-xr-x  root root system_u:object_r:mock_var_lib_t:s0 opt
>> drwxrwsr-x  root mock system_u:object_r:mock_var_lib_t:s0 proc
>> drwxr-x---  root root system_u:object_r:mock_var_lib_t:s0 root
>> drwxr-xr-x  root root system_u:object_r:mock_var_lib_t:s0 sbin
>> drwxr-xr-x  root root system_u:object_r:mock_var_lib_t:s0 selinux
>> drwxr-xr-x  root root system_u:object_r:mock_var_lib_t:s0 srv
>> drwxrwsr-x  root mock system_u:object_r:mock_var_lib_t:s0 sys
>> drwxrwxrwt  root root system_u:object_r:mock_var_lib_t:s0 tmp
>> drwxr-xr-x  root root system_u:object_r:mock_var_lib_t:s0 usr
>> drwxr-xr-x  root root system_u:object_r:mock_var_lib_t:s0 var
>>
>> (it's best to remove any cache or existing root and generate a fresh one)
>>
>> I'd like to try a version with the LD_PRELOAD back in if possible.
> 
> Well you can look at current fedora mock and run 
>     mock -r fedora-8-x86_64 init
> 
> On my local machine (with selinux enabled), I see that everything is
> labelled with "var_lib_t", like this:
> 
> $ ls -lZ
> drwxr-xr-x  root            root user_u:object_r:var_lib_t        bin
> drwxr-xr-x  root            root user_u:object_r:var_lib_t        boot
> drwx------  michael_e_brown mock user_u:object_r:var_lib_t        builddir
> drwxrwxr-x  root            root user_u:object_r:var_lib_t        dev
> ... cut ...

If you're not using the policy module, I'd expect you to have problems 
building packages that run mono and/or java code at build time as 
described at http://fedoraproject.org/wiki/PackageMaintainers/MockTricks

The package I came across that exhibited this problem and led me to 
write the policy module was "lat", a mono-based package.

> There is a current git branch with the selinux changes ported at:
> 
>     git clone http://linux.dell.com/git/mock.git
>     git checkout -b selinux origin/selinux

I built an RPM from this, and my first try at running it resulted in:

Traceback (most recent call last):
   File "/usr/libexec/mock.py", line 430, in <module>
     os.environ["LD_PRELOAD"] = LIBDIR+"/libselinux-mock.so"
NameError: name 'LIBDIR' is not defined

I added a manual definition of LIBDIR into /usr/libexec/mock.py and tt 
ran a bit further. I now get the sane file contexts that I was expecting 
but none of the scriptlets run in the target chroot because the object 
pointed to by the LD_PRELOAD isn't available in the chroot:

/bin/sh: error while loading shared libraries: 
/usr/lib64/libselinux-mock.so: cannot open shared object file: No such 
file or directory
error: %post(bash-2.05b-38.i386) scriptlet failed, exit status 127
/bin/sh: error while loading shared libraries: 
/usr/lib64/libselinux-mock.so: cannot open shared object file: No such 
file or directory
error: %post(libselinux-1.11.4-1.mockfix.fc2.i386) scriptlet failed, 
exit status 127
/bin/sh: error while loading shared libraries: 
/usr/lib64/libselinux-mock.so: cannot open shared object file: No such 
file or directory
error: %post(info-4.7-4.i386) scriptlet failed, exit status 127
/bin/sh: error while loading shared libraries: 
/usr/lib64/libselinux-mock.so: cannot open shared object file: No such 
file or directory
error: %post(sed-4.0.8-4.i386) scriptlet failed, exit status 127
/bin/sh: error while loading shared libraries: 
/usr/lib64/libselinux-mock.so: cannot open shared object file: No such 
file or directory

... and so on.

Don't know what to do about that.

Paul.




More information about the Fedora-buildsys-list mailing list