On Wed, 2006-03-29 at 22:50 +0200, Eric Tanguy wrote: > I just installed the new 2.6.16 kernel and > xorg-x11-drv-nvidia-1.0.8178-7.lvn5 > kmod-nvidia-1.0.8178-6.2.6.16_1.2080_FC5 > all seems to work fine except if i try to run glxgears : > Xlib: extension "GLX" missing on display ":0.0". > Error: couldn't get an RGB, Double-buffered visual It works if you disable selinux.

Here is what i found in audit.log concerning this problem :

What's interesting is that I don't get this error. glxgears works fine for me.

On Wed, 2006-03-29 at 13:47 -0800, Florin Andrei wrote:

> SELinux does log a few things, but it says "granted" which is why > glxgears works.

Perhaps you have the booleans allow_execmem and allow_execmod on?

On Wed, 2006-03-29 at 13:47 -0800, Florin Andrei wrote: > On Wed, 2006-03-29 at 13:42 -0800, Florin Andrei wrote: > > > What's interesting is that I don't get this error. glxgears works fine > > for me. > > SELinux does log a few things, but it says "granted" which is why > glxgears works. > > type=AVC msg=audit(1143668274.597:239): avc: granted { execmem } for > pid=4444 comm="glxgears" scontext=user_u:system_r:unconfined_t:s0 > tcontext=user_u:system_r:unconfined_t:s0 tclass=process > type=SYSCALL msg=audit(1143668274.597:239): arch=40000003 syscall=192 > success=yes exit=1183744 a0=0 a1=2000 a2=7 a3=2 items=0 pid=4444 > auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 > fsgid=500 comm="glxgears" exe="/usr/bin/glxgears" Perhaps you have the booleans allow_execmem and allow_execmod on? Paul.

On Thu, 2006-03-30 at 08:45 +0200, Eric Tanguy wrote: > Le mercredi 29 mars 2006 à 23:18 +0100, Paul Howarth a écrit : > > On Wed, 2006-03-29 at 13:47 -0800, Florin Andrei wrote: > > > On Wed, 2006-03-29 at 13:42 -0800, Florin Andrei wrote: > > > > > > > What's interesting is that I don't get this error. glxgears works > fine > > > > for me. > > > > > > SELinux does log a few things, but it says "granted" which is why > > > glxgears works. > > > > > > type=AVC msg=audit(1143668274.597:239): avc: granted { execmem } > for > > > pid=4444 comm="glxgears" scontext=user_u:system_r:unconfined_t:s0 > > > tcontext=user_u:system_r:unconfined_t:s0 tclass=process > > > type=SYSCALL msg=audit(1143668274.597:239): arch=40000003 > syscall=192 > > > success=yes exit=1183744 a0=0 a1=2000 a2=7 a3=2 items=0 pid=4444 > > > auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 > sgid=500 > > > fsgid=500 comm="glxgears" exe="/usr/bin/glxgears" > > > > Perhaps you have the booleans allow_execmem and allow_execmod on? > > > > Paul. > > > I would like to modify nothing in selinux policy to make glx. I think > this > have to work out of the box. > DO we have to wait for a new policy version ??? Try: # setsebool -P allow_execmod 1

Why not? You have to modify SELinux booleans to do all sorts of other things, like sharing home directories in samba, running a PHP application on Apache etc. As it happens, http://bugzilla.livna.org/show_bug.cgi?id=843 shows an alternative fix that could be implemented in livna's driver package (or Core policy) and you wouldn't have to set this boolean, but I wouldn't describe changing a boolean as modifying policy.

On Thu, 2006-03-30 at 09:47 -0800, Florin Andrei wrote: > On Thu, 2006-03-30 at 10:19 +0100, Paul Howarth wrote: > Indeed. > > Eric, Paul's recommendation is much better than mine. What I recommended > does amount to a "policy modification"; it's like hacking the Apache > source code to make it do what you want; it's a major change. Paul's > method is just configuration tweaking; it's like editing httpd.conf to No, you disable a whole feature just for one xorg module. Indeed, in the default file_contexts, there is a line: /usr/lib(64)?/xorg/modules/extensions/libglx\.so(\.[^/]*)* system_u:object_r:textrel_shlib_t:s0 The problem

is that livna installs the nvidia libglx in a subdirectory, so there should be an additional line: /usr/lib(64)?/xorg/modules/extensions/nvidia/libglx\.so(\.[^/]*)* system_u:object_r:textrel_shlib_t:s0

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?

> 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

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

Gérard Milmeister wrote: > On Wed, 2006-03-29 at 22:50 +0200, Eric Tanguy wrote: > >> I just installed the new 2.6.16 kernel and >> xorg-x11-drv-nvidia-1.0.8178-7.lvn5 >> kmod-nvidia-1.0.8178-6.2.6.16_1.2080_FC5 >> all seems to work fine except if i try to run glxgears : Xlib: extension >> "GLX" missing on display ":0.0". >> Error: couldn't get an RGB, Double-buffered visual >> >> what's the problem ? >> I have to enable something manually ? >> Thanks Eric >> > It works if you disable selinux. > I am getting the same message but I don't have selinux enabled since I installed with selinux=0 and I disabled it in the initial configuration screen. Xorg.0.log has no errors but says that the nvidia driver and the glx module were successfully loaded. I don't know if this is related to having an Athlon 64 dual core since many of the instructions that I have seen say load kmod-nvidia-smp but that doesn't exist for x86_64. Any suggestions welcome.

Thanks, Dan.

On Thu, 2006-03-30 at 07:28 -0800, Danny Ciarniello wrote: >I am getting the same message but I don't have selinux enabled since I >installed with selinux=0 and I disabled it in the initial configuration >screen. > > Not directly related to your question: With FC5 there's very little need to disable SELinux, unless you are in a very non-typical situation.

Hm, here i cannot compile the 8178 driver under FC5, i get this error message:

5: Fehler: »struct task_struct« has no member named »rlim«