kmod-nvidia-1.0.8178-6.2.6.16_1.2080_FC5

[Daniel J Walsh]

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)