7:18 p.m.
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
4:42 a.m.
On Sunday 26 December 2004 12:18, "Erwin J. Prinz" <ejprinz(a)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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
5:14 a.m.
New subject: FC3 " avc: denied" issue
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...
6:12 a.m.
New subject: FC3 " avc: denied" issue
On Monday 27 December 2004 22:14, Valdis.Kletnieks(a)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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
9:27 a.m.
New subject: FC3 " avc: denied" issue
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....)
9:36 a.m.
New subject: FC3 " avc: denied" issue
On Tuesday 28 December 2004 02:27, Valdis.Kletnieks(a)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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
10:04 a.m.
New subject: FC3 " avc: denied" issue
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).
2:31 p.m.
New subject: FC3 " avc: denied" issue
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
10:32 a.m.
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.
10:44 a.m.
New subject: FC3 " avc: denied" issue
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)
10:59 a.m.
New subject: FC3 " avc: denied" issue
On Mon, 2004-12-27 at 11:44 -0500, Valdis.Kletnieks(a)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.
10:47 a.m.
On Tuesday 28 December 2004 03:32, Colin Walters <walters(a)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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
11:14 a.m.
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.
12:46 p.m.
On Tuesday 28 December 2004 04:14, Colin Walters <walters(a)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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
7071
days inactive
7075
days old
selinux@lists.fedoraproject.org
13 comments
5 participants
participants (5)
-
Colin Walters -
Erwin J. Prinz -
Mike Hearn -
Russell Coker -
Valdis.Kletnieks＠vt.edu