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
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
