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.

--
Fedora-buildsys-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

Reply via email to