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

[Michael E Brown]

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 ...

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'm thinking about it a bit, and I think that the root cache might
affect this a little, because it tars/untars the chroot fs. I'll need to
do some experiments to see if there is any difference with/without root
cache enabled.
--
Michael