On Thu, 2006-03-30 at 11:59 -0500, Daniel J Walsh wrote:
> 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)
Looks like it is being overriden by a later entry in file_contexts:
/usr(/.*)?/lib(64)?/.*\.so(\.[^/]*)* -- system_u:object_r:shlib_t
--
Stephen Smalley
National Security Agency
