Stephen Smalley wrote:
On Wed, 2006-03-29 at 23:20 +0200, Eric Tanguy wrote:
Here is what i found in audit.log concerning this problem :
type=AVC msg=audit(1143664723.328:19): avc: denied { execmod } for
pid=2334 comm="Xorg" name="libglx.so.1.0.8178" dev=dm-0 ino=7504090
scontext=system_u:system_r:xdm_t:s0-s0:c0.c255
tcontext=system_u:object_r:lib_t:s0 tclass=file
type=SYSCALL msg=audit(1143664723.328:19): arch=40000003 syscall=125
success=no exit=-13 a0=164000 a1=7c000 a2=5 a3=bf983950 items=0 pid=2334
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="Xorg" exe="/usr/bin/Xorg"
type=AVC_PATH msg=audit(1143664723.328:19):
path="/usr/lib/xorg/modules/extensions/nvidia/libglx.so.1.0.8178"
The following command should mark the .so file as enabled for text
relocation (execmod):
chcon -t textrel_shlib_t /usr/lib/xorg/modules/extensions/nvidia/libglx.so.1.0.8178
To make that label persist across any subsequent relabels, you should
add an entry to file_contexts.local or use semanage, e.g.
semanage fcontext -a -t textrel_shlib_t
'/usr/lib/xorg/modules/extensions/nvidia/libglx\.so\..*'
Then a subsequent restorecon or fixfiles won't disturb it.
Possibly textrel_shlib_t should be a customizable type anyway?
No because then if the providers of the library ever clean up their
problems in the library we would not
be able to reset them.
Which version does this happen in?
In FC5 we have
/usr(/.*)?/nvidia/.*\.so(\..*)? --
gen_context(system_u:object_r:textrel_shlib_t,s0)
