I have a fully upgraded (as of today) FC3 system on which I always could install the NVIDIA drivers. But, to get a successful install after the last upgrade (today) (which included selinux-policy-targeted.noarch 1.17.30-2.58) I now have to "setenforce 0" before installing the NVIDIA drivers. Otherwise, the install fails due to several access denied issues, e.g.:
Dec 25 18:51:34 tiger kernel: audit(1104022294.445:0): avc: denied { write } for pid=3956 exe=/sbin/ldconfig path=/var/log/nvidia-installer.log dev=hda6 ino=517383 scontext=root:system_r:ldconfig_t tcontext=system_u:object_r:var_log_t tclass=file Dec 25 18:51:34 tiger kernel: audit(1104022294.801:0): avc: denied { read } for pid=3956 exe=/sbin/ldconfig name=libXvMCNVIDIA.so.1.0.6629 dev=hda4 ino=194830 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file Dec 25 18:51:35 tiger kernel: audit(1104022295.012:0): avc: denied { getattr } for pid=3956 exe=/sbin/ldconfig path=/usr/X11R6/lib/libXvMCNVIDIA.so.1.0.6629 dev=hda4 ino=194830 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file Dec 25 18:51:38 tiger kernel: audit(1104022298.997:0): avc: denied { getattr } for pid=3956 exe=/sbin/ldconfig path=/usr/lib/libGL.so.1.0.6629 dev=hda4 ino=521611 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file/avc
The initial context of root is "root:system_r:unconfined_t" and I can't change to "root:sysadm_r:sysadm_t". I did a "fixfiles relabel" and reboot without changing the outcome.
I don't think the issue is with the NVIDIA drivers as they worked on FC3 before, and as "setenforce 0" "fixes" the issue.
I would appreciate pointers to what could be wrong.
Best regards, Erwin
On Sunday 26 December 2004 12:18, "Erwin J. Prinz" ejprinz@austin.rr.com wrote:
Dec 25 18:51:34 tiger kernel: audit(1104022294.445:0): avc: denied { write } for pid=3956 exe=/sbin/ldconfig path=/var/log/nvidia-installer.log dev=hda6 ino=517383 scontext=root:system_r:ldconfig_t tcontext=system_u:object_r:var_log_t tclass=file
Looks like the command is "ldconfig >> /var/log/nvidia-installer.log", this is no problem, ldconfig generally doesn't give any interesting output.
Dec 25 18:51:35 tiger kernel: audit(1104022295.012:0): avc: denied { getattr } for pid=3956 exe=/sbin/ldconfig path=/usr/X11R6/lib/libXvMCNVIDIA.so.1.0.6629 dev=hda4 ino=194830 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file
The file contexts seem OK for that. I guess that you installed it from a .tar file not an rpm package and didn't use restorecon to fix it's label.
Dec 25 18:51:38 tiger kernel: audit(1104022298.997:0): avc: denied { getattr } for pid=3956 exe=/sbin/ldconfig path=/usr/lib/libGL.so.1.0.6629 dev=hda4 ino=521611 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file
Report a bug to whoever provided the collection of files that their install script should do the following: restorecon /usr/X11R6/lib/libXvMCNVIDIA.so.1.0.6629 restorecon /usr/lib/libGL.so.1.0.6629
I don't think the issue is with the NVIDIA drivers as they worked on FC3 before, and as "setenforce 0" "fixes" the issue.
FC3 has SE Linux enabled by default. Anything that is designed for FC3 has to be designed to work with SE Linux. It seems that the NVIDIA driver archive is not designed to do so. It would be much easier if they just provided a RPM.
On Mon, 27 Dec 2004 21:42:03 +1100, Russell Coker said:
Report a bug to whoever provided the collection of files that their install script should do the following: restorecon /usr/X11R6/lib/libXvMCNVIDIA.so.1.0.6629 restorecon /usr/lib/libGL.so.1.0.6629
also you may need this:
restorecon /dev/nvidia*
(this one is already in the Fedora .fc files, but you may have mislabeled versions until you relabel them...)
FC3 has SE Linux enabled by default. Anything that is designed for FC3 has to be designed to work with SE Linux. It seems that the NVIDIA driver archive is not designed to do so. It would be much easier if they just provided a RPM.
The problem is that they didn't drink the "All Linux is RedHat RPM-based" kool-aid.
They're additionally hobbled by the fact that they have a userspace component (where the .so's came from) and a kernel module - and if either userspace and module, or module and kernel, get out of sync, things Fail Very Badly.
Currently, they ship *one* release that will work out-of-the-box for literally 134 or so different distro/release/kernel combos. For *JUST* the Fedora releases, they have:
fedora1boot_2.4.22-1.2115.nptl_i386 fedora1boot_2.4.22-1.2188.nptl_i386 fedora1smp_2.4.22-1.2115.nptl_athlon fedora1smp_2.4.22-1.2115.nptl_i686 fedora1smp_2.4.22-1.2188.nptl_athlon fedora1smp_2.4.22-1.2188.nptl_i686 fedora1up_2.4.22-1.2115.nptl_athlon fedora1up_2.4.22-1.2115.nptl_i586 fedora1up_2.4.22-1.2115.nptl_i686 fedora1up_2.4.22-1.2188.nptl_athlon fedora1up_2.4.22-1.2188.nptl_i586 fedora1up_2.4.22-1.2188.nptl_i686 fedora2smp_2.6.5-1.358_i586 fedora2smp_2.6.5-1.358_i686 fedora2smp_2.6.8-1.521_i586 fedora2smp_2.6.8-1.521_i686 fedora2up_2.6.5-1.358_i586 fedora2up_2.6.5-1.358_i686 fedora2up_2.6.8-1.521_i586 fedora2up_2.6.8-1.521_i686
There's also RH 7.2->9.0 and RHEL 3.0 and Mandrake 8.1->10 and Suse prebuilts.
Currently, *any* of those users can get *the same package*, run the installer, and things Just Work. Otherwise, they get the support problem of shipping 134 different RPM's (which is not THAT bad, really), and making sure the people actually download the *RIGHT* one (can you say "help desk nightmare"?)
In fact, once upon a time, they *did* ship RPMs. And the support issues were why they went to shipping an installer instead...
On Monday 27 December 2004 22:14, Valdis.Kletnieks@vt.edu wrote:
FC3 has SE Linux enabled by default. Anything that is designed for FC3 has to be designed to work with SE Linux. It seems that the NVIDIA driver archive is not designed to do so. It would be much easier if they just provided a RPM.
The problem is that they didn't drink the "All Linux is RedHat RPM-based" kool-aid.
Do you think that I have drunk such kool-aid? I was a Debian developer for many years before joining Red Hat.
They're additionally hobbled by the fact that they have a userspace component (where the .so's came from) and a kernel module - and if either userspace and module, or module and kernel, get out of sync, things Fail Very Badly.
They designed it badly. Keeping interfaces synchronised isn't that difficult, all the code that gets into the main-line kernel keeps the interfaces the same for long periods of time. Interface changes have version numbers and applications can (if necessary) support both interfaces.
From what you are telling me the first thing that they need to do is to design
an interface between user-space and the kernel code.
Currently, they ship *one* release that will work out-of-the-box for literally 134 or so different distro/release/kernel combos. For *JUST* the Fedora releases, they have:
There's also RH 7.2->9.0 and RHEL 3.0 and Mandrake 8.1->10 and Suse prebuilts.
If they are producing multiple packages for each distribution then they must have the builds automated. It should be quite easy to make an automatic build script that builds RPMs, Debian packages, and any other types of package that seem necessary.
Currently, *any* of those users can get *the same package*, run the installer, and things Just Work. Otherwise, they get the support problem of shipping 134 different RPM's (which is not THAT bad, really), and making sure the people actually download the *RIGHT* one (can you say "help desk nightmare"?)
If the interface between kernel and user-space doesn't change then all they need to do is have one RPM for the shared objects and a set of RPMs that install .ko's in the correct places for each kernel. You would just have to make sure that every time you upgrade your kernel you install the matching drivers. If you didn't install the drivers then the symptom would be a lack of 3D graphics which would be easy to fix.
On Mon, 27 Dec 2004 23:12:42 +1100, Russell Coker said:
If they are producing multiple packages for each distribution then they must have the builds automated. It should be quite easy to make an automatic build script that builds RPMs, Debian packages, and any other types of package that seem necessary.
As I said, that's the easy part.
If the interface between kernel and user-space doesn't change then all they need to do is have one RPM for the shared objects and a set of RPMs that install .ko's in the correct places for each kernel. You would just have to make sure that every time you upgrade your kernel you install the matching drivers. If you didn't install the drivers then the symptom would be a lack of 3D graphics which would be easy to fix.
The reason why "they" did it the way "they" did, with one installer for everybody, was precisely because all the "you" out there would encounter issues with "install the matching drivers" - what qualifies as "easy to fix" for most readers of this list results in a call to the vendor for Joe Sixpack.
(Hell, just the last 48 hours I had a mysterious X.org issue caused by two conflicting NVidia libraries, a crufty one in one directory, a current version in another, and the symptoms depended on what order ldconfig found things in ld.so.conf....)
On Tuesday 28 December 2004 02:27, Valdis.Kletnieks@vt.edu wrote:
If the interface between kernel and user-space doesn't change then all they need to do is have one RPM for the shared objects and a set of RPMs that install .ko's in the correct places for each kernel. You would just have to make sure that every time you upgrade your kernel you install the matching drivers. If you didn't install the drivers then the symptom would be a lack of 3D graphics which would be easy to fix.
The reason why "they" did it the way "they" did, with one installer for everybody, was precisely because all the "you" out there would encounter issues with "install the matching drivers" - what qualifies as "easy to fix" for most readers of this list results in a call to the vendor for Joe Sixpack.
So what do they do instead? Force a binary-only module to be loaded into a kernel of a version other than the one it was created for? That's a recipe for disaster! I hope that the users of the NVidia drivers don't have any important data on their machines...
(Hell, just the last 48 hours I had a mysterious X.org issue caused by two conflicting NVidia libraries, a crufty one in one directory, a current version in another, and the symptoms depended on what order ldconfig found things in ld.so.conf....)
It seems that the NVidia drivers suck in many ways. What's the best option for 3D graphics in Linux nowadays? Not NVidia I guess.
On Tue, 28 Dec 2004 02:36:07 +1100, Russell Coker said:
So what do they do instead? Force a binary-only module to be loaded into a kernel of a version other than the one it was created for? That's a recipe for disaster! I hope that the users of the NVidia drivers don't have any important data on their machines...
No, what they do is a big binary-only blob, and a little 30K shim for each kernel version (even compiling one from source if it's a kernel it doesn't know but there's a usable source tree to build against).
(Hell, just the last 48 hours I had a mysterious X.org issue caused by two conflicting NVidia libraries, a crufty one in one directory, a current version in another, and the symptoms depended on what order ldconfig found things in ld.so.conf....)
It seems that the NVidia drivers suck in many ways.
No, this one was self-inflicted. :) Merely intended to point out the sort of user screw-ups they need to worry about (what, you don't think some user is going to say 'rpm -Uvh --force' to get the wrong version installed and then call for help? ;)
NVidia *is* trying to DTRT thing here - they're hampered by the fact that a lot of their code is licensed from others. The most productive thing to do here is to collectively figure out what NVidia's installer needs to do to cooperate with the FC3/4 environment (there's several SELinux gotchas, and it probably needs to leave the right clues for udev - after the latest udev RPM went on my laptop this weekend, my /dev/nvidia* devices didn't show up at next reboot).
It looks like the SELinux policy already has all the needed hooks for NVidia, just their installer needs to make sure it nails *all* the right 'restorecon' commands (at least for SELinux issues).
On Tue, 28 Dec 2004 02:36:07 +1100, Russell Coker wrote:
It seems that the NVidia drivers suck in many ways. What's the best option for 3D graphics in Linux nowadays? Not NVidia I guess.
nVidia has been the best option for 3D on Linux for a very long time now. Their drivers are high quality and Just Work to a far greater extent than the only real competitions, ATIs. They also allow unlimited redistribution of their drivers, so eg I get mine via yum.
thanks -mike
On Mon, 2004-12-27 at 21:42 +1100, Russell Coker wrote:
Report a bug to whoever provided the collection of files that their install script should do the following: restorecon /usr/X11R6/lib/libXvMCNVIDIA.so.1.0.6629 restorecon /usr/lib/libGL.so.1.0.6629
Dan recently worked on a patch for coreutils to make the 'install' command do this internally. I don't think we can ask every ISV to insert restorecon commands at arbitrary points in their code. Saying however that they must use the 'install' command (or RPM) to install software is a much more defensible position, IMO.
On Mon, 27 Dec 2004 11:32:41 EST, Colin Walters said:
Dan recently worked on a patch for coreutils to make the 'install' command do this internally. I don't think we can ask every ISV to insert restorecon commands at arbitrary points in their code. Saying however that they must use the 'install' command (or RPM) to install software is a much more defensible position, IMO.
Any opinions on how they should integrate their current 'mknod' commands, which currently need a restorecon? Should mknod handle it, or is that part still NVidia's problem? (I suppose it would be OK to push *that* one back at the sofware - many packages install dozens or even hundreds of regular files, but rarely use mknod (even the NVidia one has some 35 files and only 7 mknod's)
On Mon, 2004-12-27 at 11:44 -0500, Valdis.Kletnieks@vt.edu wrote:
On Mon, 27 Dec 2004 11:32:41 EST, Colin Walters said:
Dan recently worked on a patch for coreutils to make the 'install' command do this internally. I don't think we can ask every ISV to insert restorecon commands at arbitrary points in their code. Saying however that they must use the 'install' command (or RPM) to install software is a much more defensible position, IMO.
Any opinions on how they should integrate their current 'mknod' commands, which currently need a restorecon? Should mknod handle it, or is that part still NVidia's problem? (I suppose it would be OK to push *that* one back at the sofware - many packages install dozens or even hundreds of regular files, but rarely use mknod (even the NVidia one has some 35 files and only 7 mknod's)
Yeah; I think anything that calls mknod is a special case, since it is very low-level and inherently Linux-specific. Asking those ISVs to suffix mknod invocations with something like: test -x /sbin/restorecon && /sbin/restorecon /dev/nvidia isn't too onerous. At least until we have some sort of API for these vendors to add device files. (Although it's unclear to me why they need to create device files at all; shouldn't udev be creating it dynamically when their kernel module is inserted?)
But the larger issue here of breaking the general './configure;make;make install' is very bad; I hope Dan's patch will fix this.
On Tuesday 28 December 2004 03:32, Colin Walters walters@redhat.com wrote:
On Mon, 2004-12-27 at 21:42 +1100, Russell Coker wrote:
Report a bug to whoever provided the collection of files that their install script should do the following: restorecon /usr/X11R6/lib/libXvMCNVIDIA.so.1.0.6629 restorecon /usr/lib/libGL.so.1.0.6629
Dan recently worked on a patch for coreutils to make the 'install' command do this internally. I don't think we can ask every ISV to insert restorecon commands at arbitrary points in their code. Saying however that they must use the 'install' command (or RPM) to install software is a much more defensible position, IMO.
Valdis just said that they have specific builds for different distributions and different versions of the various distributions. As they already have such a variation, adding another simple thing such as restorecon is not asking a lot (IMHO).
Also if they would just use RPMs to deliver their software then many of these issues would get solved for them.
On Tue, 2004-12-28 at 03:47 +1100, Russell Coker wrote:
Valdis just said that they have specific builds for different distributions and different versions of the various distributions. As they already have such a variation, adding another simple thing such as restorecon is not asking a lot (IMHO).
If you just view this in the specific context of NVidia, sure, we could probably browbeat them into adding a bit more goo to their code.
But the larger issue here is keeping 'make install' working for the vast majority of software out there (the ones that don't create device files, etc). I see tons of reports in Bugzilla from people confused as to why this breaks on Fedora, and for good reason. You need to think of our existing software infrastructure, from filesystem paths like "/usr/local/lib" to tools like "install" and "ldconfig" as an API. We've told ISVs (and I'm not just talking about proprietary software here; an ISV could also be software like a Xine tarball) that they can integrate with our system by using 'install' to a few filesystem paths, and running the magic command 'ldconfig'.
If we all of a sudden tell them that they have to run some additional magic command, we are breaking that API. And that's wrong, *especially* in this case because the breakage is mostly needless; I think Dan's patch for "install" should cover the vast majority of cases.
Breaking this API is wrong because not only will it lead to a higher support burden for us (and if you watch Bugzilla, it clearly *has* lead to that), it will also lead to people recommending to turn off SELinux.
On Tuesday 28 December 2004 04:14, Colin Walters walters@redhat.com wrote:
On Tue, 2004-12-28 at 03:47 +1100, Russell Coker wrote:
Valdis just said that they have specific builds for different distributions and different versions of the various distributions. As they already have such a variation, adding another simple thing such as restorecon is not asking a lot (IMHO).
If you just view this in the specific context of NVidia, sure, we could probably browbeat them into adding a bit more goo to their code.
They certainly need to add more "goo". The issue of udev that was mentioned is another thing that they need to fix.
But the larger issue here is keeping 'make install' working for the vast
I agree that adding such support to install is a good thing.
selinux@lists.fedoraproject.org