Bug 179656

Summary: NVIDIA proprietary X driver policy updates needed
Product: [Fedora] Fedora Reporter: Ville Skyttä <scop>
Component: selinux-policy-targetedAssignee: Daniel Walsh <dwalsh>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: Axel.Thimm, fedora, netllama, tim.fenn
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 2.2.16-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-23 20:19:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch for updated location of NVIDIA libGL*
none
audit.log from unsuccessful X startup
none
ATrpms nvidia file_contexts adjustments none

Description Ville Skyttä 2006-02-01 21:57:28 UTC
The NVIDIA proprietary X driver things need updating in the targeted policy:

First, the NVIDIA libGL* libs are in the /usr/lib(64)/nvidia dir on my box
(package from livna.org).  Patch attached.

Second, when starting X, I get this in logs:
(II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so
dlopen: /usr/lib64/xorg/modules/drivers/nvidia_drv.so: cannot enable executable
stack as shared object requires: Permission denied
(EE) Failed to load /usr/lib64/xorg/modules/drivers/nvidia_drv.so

"execstack -c /usr/lib64/xorg/modules/drivers/nvidia_drv.so" fixes it.  Is there
a way to accomplish that in the selinux policy out of the box?

Comment 1 Ville Skyttä 2006-02-01 21:57:28 UTC
Created attachment 123997 [details]
Patch for updated location of NVIDIA libGL*

Comment 2 Daniel Walsh 2006-02-14 20:37:41 UTC
Fixed in selinux-policy-2.2.15-2

Comment 3 Ville Skyttä 2006-02-17 16:33:30 UTC
Created attachment 124821 [details]
audit.log from unsuccessful X startup

The library permissions seem to be fixed in 2.2.15-4, but the problem with
nvidia_drv.so (see initial comment) persists.  audit.log snippet from
unsuccessful X/gdm startup attached.

Comment 4 Daniel Walsh 2006-02-20 16:15:57 UTC
selinux-policy-2.2.16-1 Adds the execstack priv to xserver, although it would be
good to report this as a bug to nvidia.

Dan

Comment 5 Ville Skyttä 2006-02-23 20:19:11 UTC
Confirmed working and reported at
http://www.nvnews.net/vbulletin/showthread.php?t=65363

Comment 6 Lonni J Friedman 2006-02-23 20:38:46 UTC
NVIDIA has bug 207999 open for this issue.

Thanks,
Lonni

Comment 7 Axel Thimm 2006-03-31 10:58:54 UTC
Dan, could you also add ATrpms' paths to selinux-policy? E.g. something like

-/usr/lib(64)?/xorg/modules/extensions/nvidia/libglx\.so(\.[^/]*)* --
gen_context(system_u:object_r:textrel_shlib_t,s0)
+/usr/lib(64)?/xorg/modules/extensions/nvidia(-[^/]*)?/libglx\.so(\.[^/]*)* --
gen_context(system_u:object_r:textrel_shlib_t,s0)

Thanks!

(BTW who do I need to contact to get appropriate right to reopen bugs?)


Comment 8 Daniel Walsh 2006-03-31 16:49:03 UTC
This is a sorting problem in FC5.  The context is in the file, but it is being
overridden by a path later in the file.  I will update the policy to fix the
problem.

As far as who to contact, I have no idea.

Dan

Comment 9 Tim Fenn 2006-03-31 18:17:02 UTC
Created attachment 127143 [details]
ATrpms nvidia file_contexts adjustments

Comment 10 Tim Fenn 2006-03-31 18:18:24 UTC
I've attached the full list of modifications to file_contexts required for the
ATrpms nvidia drivers, which includes the glx and GLcore changes.

Comment 11 Thorsten Leemhuis 2006-04-01 07:49:20 UTC
(In reply to comment #8)
> This is a sorting problem in FC5.  The context is in the file, but it is being
> overridden by a path later in the file.  I will update the policy to fix the
> problem.

Dan, could you also take a look at Bug #187476 please -- a lot of livna users
are hitting this currently

Comment 12 Axel Thimm 2006-08-14 08:55:40 UTC
(In reply to comment #8)
> I will update the policy to fix the problem.

I think this got forgotten, because Tim's comment #7 was done after the bug was
closed, so I'm reopening it (unless you prefer to clone the bug instead?)

I received a bug report from a strict policy user (this is targeted, but I guess
the fix/bug will be the same), that's how I remembered this one.

Thanks!