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_ubject_r:bin_t:s0 bin
drwxr-xr-x root root system_ubject_r:boot_t:s0 boot
drwx------ root mock system_ubject_r:mock_var_lib_t:s0 builddir
drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 dev
drwxr-xr-x root root system_ubject_r:etc_t:s0 etc
drwxr-xr-x root root system_ubject_r:home_root_t:s0 home
drwxr-xr-x root root system_ubject_r:root_t:s0 initrd
drwxr-xr-x root root system_ubject_r:lib_t:s0 lib
drwxr-xr-x root root system_ubject_r:mnt_t:s0 mnt
drwxr-xr-x root root system_ubject_r:usr_t:s0 opt
drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 proc
drwxr-x--- root root system_ubject_r:user_home_dir_t:s0 root
drwxr-xr-x root root system_ubject_r:bin_t:s0 sbin
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 selinux
drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 sys
drwxrwxrwt root root system_ubject_r:tmp_t:s0 tmp
drwxr-xr-x root root system_ubject_r:usr_t:s0 usr
drwxr-xr-x root root system_ubject_r:var_t:s0 var

rather than this:
/var/lib/mock/fedora-3-i386-core/root:
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 bin
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 boot
drwx------ paul mock system_ubject_r:mock_var_lib_t:s0 builddir
drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 dev
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 etc
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 home
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 initrd
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 lib
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 media
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 mnt
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 opt
drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 proc
drwxr-x--- root root system_ubject_r:mock_var_lib_t:s0 root
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 sbin
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 selinux
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 srv
drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 sys
drwxrwxrwt root root system_ubject_r:mock_var_lib_t:s0 tmp
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 usr
drwxr-xr-x root root system_ubject_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.

Paul.

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

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_ubject_r:bin_t:s0 bin
> drwxr-xr-x root root system_ubject_r:boot_t:s0 boot
> drwx------ root mock system_ubject_r:mock_var_lib_t:s0 builddir
> drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 dev
> drwxr-xr-x root root system_ubject_r:etc_t:s0 etc
> drwxr-xr-x root root system_ubject_r:home_root_t:s0 home
> drwxr-xr-x root root system_ubject_r:root_t:s0 initrd
> drwxr-xr-x root root system_ubject_r:lib_t:s0 lib
> drwxr-xr-x root root system_ubject_r:mnt_t:s0 mnt
> drwxr-xr-x root root system_ubject_r:usr_t:s0 opt
> drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 proc
> drwxr-x--- root root system_ubject_r:user_home_dir_t:s0 root
> drwxr-xr-x root root system_ubject_r:bin_t:s0 sbin
> drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 selinux
> drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 sys
> drwxrwxrwt root root system_ubject_r:tmp_t:s0 tmp
> drwxr-xr-x root root system_ubject_r:usr_t:s0 usr
> drwxr-xr-x root root system_ubject_r:var_t:s0 var
>
> rather than this:
> /var/lib/mock/fedora-3-i386-core/root:
> drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 bin
> drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 boot
> drwx------ paul mock system_ubject_r:mock_var_lib_t:s0 builddir
> drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 dev
> drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 etc
> drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 home
> drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 initrd
> drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 lib
> drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 media
> drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 mnt
> drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 opt
> drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 proc
> drwxr-x--- root root system_ubject_r:mock_var_lib_t:s0 root
> drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 sbin
> drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 selinux
> drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 srv
> drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 sys
> drwxrwxrwt root root system_ubject_r:mock_var_lib_t:s0 tmp
> drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 usr
> drwxr-xr-x root root system_ubject_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_ubject_r:var_lib_t bin
drwxr-xr-x root root user_ubject_r:var_lib_t boot
drwx------ michael_e_brown mock user_ubject_r:var_lib_t builddir
drwxrwxr-x root root user_ubject_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

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

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_ubject_r:bin_t:s0 bin
drwxr-xr-x root root system_ubject_r:boot_t:s0 boot
drwx------ root mock system_ubject_r:mock_var_lib_t:s0 builddir
drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 dev
drwxr-xr-x root root system_ubject_r:etc_t:s0 etc
drwxr-xr-x root root system_ubject_r:home_root_t:s0 home
drwxr-xr-x root root system_ubject_r:root_t:s0 initrd
drwxr-xr-x root root system_ubject_r:lib_t:s0 lib
drwxr-xr-x root root system_ubject_r:mnt_t:s0 mnt
drwxr-xr-x root root system_ubject_r:usr_t:s0 opt
drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 proc
drwxr-x--- root root system_ubject_r:user_home_dir_t:s0 root
drwxr-xr-x root root system_ubject_r:bin_t:s0 sbin
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 selinux
drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 sys
drwxrwxrwt root root system_ubject_r:tmp_t:s0 tmp
drwxr-xr-x root root system_ubject_r:usr_t:s0 usr
drwxr-xr-x root root system_ubject_r:var_t:s0 var

rather than this:
/var/lib/mock/fedora-3-i386-core/root:
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 bin
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 boot
drwx------ paul mock system_ubject_r:mock_var_lib_t:s0 builddir
drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 dev
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 etc
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 home
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 initrd
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 lib
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 media
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 mnt
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 opt
drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 proc
drwxr-x--- root root system_ubject_r:mock_var_lib_t:s0 root
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 sbin
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 selinux
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 srv
drwxrwsr-x root mock system_ubject_r:mock_var_lib_t:s0 sys
drwxrwxrwt root root system_ubject_r:mock_var_lib_t:s0 tmp
drwxr-xr-x root root system_ubject_r:mock_var_lib_t:s0 usr
drwxr-xr-x root root system_ubject_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_ubject_r:var_lib_t bin
drwxr-xr-x root root user_ubject_r:var_lib_t boot
drwx------ michael_e_brown mock user_ubject_r:var_lib_t builddir
drwxrwxr-x root root user_ubject_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
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

On Mon, Dec 03, 2007 at 04:49:41PM +0000, Paul Howarth wrote:
> Michael E Brown wrote:
> 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
>
> ... and so on.
>
> Don't know what to do about that.

The selinux stuff was only lightly tested. Looks like it still needs
work. Looks like I missed something when I rebased to HEAD.

I'll take another look at it, and also check out lat.

--
Michael




--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

On Mon, Dec 03, 2007 at 04:39:26PM -0600, Michael E Brown wrote:
> On Mon, Dec 03, 2007 at 04:49:41PM +0000, Paul Howarth wrote:
> > Michael E Brown wrote:
> > 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

Can you explain to me what you mean by "if you're not using the policy
module"? I'm sorta-slow when it comes to selinux (as evidenced by this
thread...)

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

Using unmodified current mock (0.8.12) on Fedora 8 with selinux
enforcing, I was able to compile current F8 lat:

$ mock -r fedora-8-x86_64 --rebuild --resultdir=./try/out ./try/lat-1.2.3-1.fc8.src.rpm
INFO: mock.py version 0.8.12 starting...
State Changed: init plugins
State Changed: start
State Changed: lock buildroot
State Changed: clean
INFO: Start(./try/lat-1.2.3-1.fc8.src.rpm) Config(fedora-8-x86_64)
State Changed: init
State Changed: lock buildroot
INFO: enabled yum cache
State Changed: cleaning yum metadata
INFO: enabled root cache
State Changed: unpacking cache
State Changed: running yum
State Changed: setup
State Changed: build
INFO: Done(./try/lat-1.2.3-1.fc8.src.rpm) Config(fedora-8-x86_64) 9 minutes 42 seconds
INFO: Results and/or logs in: ./try/out
INFO: Cleaning up build root ('clean_on_success=True')
State Changed: lock buildroot
State Changed: clean

--
Michael

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

Michael E Brown wrote:

On Mon, Dec 03, 2007 at 04:39:26PM -0600, Michael E Brown wrote:

On Mon, Dec 03, 2007 at 04:49:41PM +0000, Paul Howarth wrote:

Michael E Brown wrote:
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


Can you explain to me what you mean by "if you're not using the policy
module"? I'm sorta-slow when it comes to selinux (as evidenced by this
thread...)


I'm referring to the SELinux policy module attached to the wiki page:
http://fedoraproject.org/wiki/PackageMaintainers/MockTricks

There's a description of the problem (at least as it was in FC5) on that
page.


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


Using unmodified current mock (0.8.12) on Fedora 8 with selinux
enforcing, I was able to compile current F8 lat:

$ mock -r fedora-8-x86_64 --rebuild --resultdir=./try/out ./try/lat-1.2.3-1.fc8.src.rpm
INFO: mock.py version 0.8.12 starting...

State Changed: init plugins
State Changed: start
State Changed: lock buildroot
State Changed: clean
INFO: Start(./try/lat-1.2.3-1.fc8.src.rpm) Config(fedora-8-x86_64)
State Changed: init
State Changed: lock buildroot
INFO: enabled yum cache
State Changed: cleaning yum metadata
INFO: enabled root cache
State Changed: unpacking cache
State Changed: running yum
State Changed: setup
State Changed: build
INFO: Done(./try/lat-1.2.3-1.fc8.src.rpm) Config(fedora-8-x86_64) 9 minutes 42 seconds
INFO: Results and/or logs in: ./try/out
INFO: Cleaning up build root ('clean_on_success=True')
State Changed: lock buildroot
State Changed: clean


I'm also unable to reproduce the problem at this time, but I believe
that that's because of the labelling issue, which is masking the problem.


After building lat, try this:
# ls -lZ /var/lib/mock/fedora-8-x86_64/root/usr/bin/mono

I get:
-rwxr-xr-x root root system_ubject_r:mono_exec_t:s0
/var/lib/mock/fedora-8-x86_64/root/usr/bin/mono


With the LD_PRELOAD, this would have been var_lib_t or mock_var_lib_t,
depending on whether you were using the policy module. I'd expect the
build to fail with this file not labelled as mono_exec_t, due to execmod
errors.


If you get var_lib_t for this file, could you try removing any cache for
this root, and also the root itself (/var/lib/mock/fedora-8-x86_64/root)
and try again?


Paul.

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

Michael E Brown wrote:

On Mon, Dec 03, 2007 at 04:49:41PM +0000, Paul Howarth wrote:

Michael E Brown wrote:
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


... and so on.

Don't know what to do about that.


The selinux stuff was only lightly tested. Looks like it still needs
work. Looks like I missed something when I rebased to HEAD.


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.


Paul.

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

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

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

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.

This version passes all unit tests with no messages about missing
libraries, and also unsets LD_PRELOAD prior to running mock.

Could you please give it a runthrough and see if you notice it doing
anything? I get the same (nonfatal) AVC denials that I get without the
patch when running in enforcing mode.
--
Michael

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list

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.


This version passes all unit tests with no messages about missing
libraries, and also unsets LD_PRELOAD prior to running mock.


Great.


Could you please give it a runthrough and see if you notice it doing
anything? I get the same (nonfatal) AVC denials that I get without the
patch when running in enforcing mode.


I think that any AVCs, even if they don't cause build failures, are a
problem; they add clutter to the audit log, can pop up an setroubleshoot
alert on the desktop and may hide other problems unrelated to mock.


Could you post some examples of the AVCs youre getting?

Could you also test the version with the LD_PRELOAD after removing the
target root entirely and also any root cache and see if you still get
the denials. If you do get any denials, could you check (ls -lZ) if any
of the files installed in the target's /bin, /sbin, /usr/bin, /usr/sbin
directories have context types ending in _exec_t?


Paul.

--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list