/etc/security/console.perm file

[dishawjp]

Hi All,

It appears that I've managed to cause a problem with my NVidia drivers... somehow. I'm unable to run Chromium or Tuxracer or anything else that requires 3D accelleration. The error message from Chromium was:

[dishawjp@eunix dishawjp]$ chromium
randomizing.
SDL initialized.
Error: Could not open /dev/nvidiactl because the permissions
are too resticitive. Please see the FREQUENTLY ASKED QUESTIONS
section of /usr/share/doc/NVIDIA_GLX-1.0/README for steps
to correct.

That seemed to be pretty simple so I went to the FAQ section of that file and it told me to delete the line beginning with <dri> which referred to my NVidia driver:

Q: OpenGL applications exit with the following error message:

Error: Could not open /dev/nvidiactl because the permissions
are too restrictive. Please see the FREQUENTLY ASKED QUESTIONS
section of /usr/share/doc/NVIDIA_GLX-1.0/README for steps
to correct.

A: It is likely that a security module for the PAM system may be
changing the permissions on the NVIDIA device files. In most cases
this security system works, but it can get confused. To correct this
problem it is recommended that you disable this security feature.
Different Linux distributions have different files to control this;
please consult with your distributor for the correct method of
disabling this security feature. As an example, if your system has
the file
/etc/security/console.perms
then you should edit the file and remove the line that starts with
"<dri>"

So what I tried was to comment the <dri> line out using a "#" to give it a test run. There was much unhappiness and a critical error on boot up whining about an unrecognized <dri> line. Then I was only able to log on as root. I removed the offending hash and everything returned to its former state.

Should I really consider removing this line? I know that I could do a "cp console.perm console.perm.old" or something like that and probably recover if bad things happened, but am worried about doing more seroius damage to the system.

Any thoughts?

Jim Dishaw

[Void Main]

What you did *should* have worked but you can make a backup of the file as you mentioned and remove the line. I would assume that you would then want to:

# chmod a+rw /dev/dri/*
# chmod a+rw /dev/nvidia/*

but it doesn't say that in the FAQ.

[dishawjp]

Hi Voidmain,

I didn't get a chance to try your recommendations last night, but want to have a go at it tonight. Your suggestion seems to make more sense than what is recommended in the FAQ. I went into /dev and looked at the files that you suggested. It seems that they are all owned by root:

[dishawjp@eunix dev]$ ls -l dri/card?
crw------- 1 root root 226, 0 Jan 30 05:24 dri/card0
crw------- 1 root root 226, 1 Jan 30 05:24 dri/card1
crw------- 1 root root 226, 2 Jan 30 05:24 dri/card2
crw------- 1 root root 226, 3 Jan 30 05:24 dri/card3
[dishawjp@eunix dev]$ ls -l nvid*
crw------- 1 root root 195, 0 May 9 20:43 nvidia0
crw------- 1 root root 195, 1 May 9 20:43 nvidia1
crw------- 1 root root 195, 2 May 9 20:43 nvidia2
crw------- 1 root root 195, 3 May 9 20:43 nvidia3
crw------- 1 root root 195, 4 May 9 20:43 nvidia4
crw------- 1 root root 195, 5 May 9 20:43 nvidia5
crw------- 1 root root 195, 6 May 9 20:43 nvidia6
crw------- 1 root root 195, 7 May 9 20:43 nvidia7
crw------- 1 root root 195, 255 May 9 20:43 nvidiactl

I'm going to show my lack of Linux knowledge to the world.. again... I have no idea what the "c" in the ownership part of the directory listing means. I know about r, w, x and d, but what does the "c" stand for and how, if it managed to make my baby unhappy, would I restore that attribute to these files?

The reaction I got when I edited the console.perms file makes me a bit reluctant to mess with this until I know how to back out if things get unpleasant.

Thanks again!

Jim Dishaw

[Void Main]

The "c" just means it's a special type of device file, more specifically a "character device". You'll notice your hard drive and floppy devices have a "b" in the permissions list which means they are "block devices". Symbolic links start with an "l", directories start with "d", sockets start with "s", pipes start with "p", and of course regular files start with a "-". That's all of them that I can think of. You use the "mknod" command to create many of the special files mentioned. Of course you use "ln -s" to create symbolic links and "mkdir" to create directories. At any rate, that is not something you can change with the "chmod" command so just doing a "chmod a+rw /dev/nvidia/* /dev/dri/*" should give your apps access to the devices. I'm not sure that they should need that access though but it wouldn't hurt to try it...

To expand on the above there are still a few more characters you will see besides "r", "w", and "x" in the permissions columns (not the first column). You can have "s", "S", "t", and possibly some more that I'm not thinking of...

[dishawjp]

Thanks again for everything.

I edited my /etc/security/console.perms file again; this time deleting the <dri> line as suggested in the FAQ. I had already done the chmod as you had suggested, and was back to the critical error and had root assess at runlevel 3 only. So I deleted the console.perms and replaced it with the console.perms.old I had created and am back in business... just no 3D accelleration.

I have rechecked my /etc/X11/XF86Config file to be sure that it was properly edited... replace "nv" with "nvidia" and all. Everything there was still good.

Might it make sense to rerun the "NVIDIA-Linux-x86-1.0-4363.run" install again? I kept a copy of it after my initail install, and for a while I did have 3D operation. I don't know what I did to hose it.

Let me know if that makes sense or if that could end up doing more damage.

thanks again,

Jim Dishaw

[Void Main]

I do have an nVidia card but I rarely use the console on the machine it is in (I terminal server into it from my laptop) so I don't really run any 3d apps. An occasional GL game but that is rare... I would suggest asking the question on the nVidia forum:

http://www.nvnews.net/vbulletin/forumdi ... forumid=14

[dishawjp]

Thanks for the suggestion Voidmain,

Before posting to nvnews, I figured I didn't have much to lose, so I rechecked my /etc/X11/XF86Config file (it was fine) and then reran my NVidia driver install.

I don't know how it had gotten messed up, but the driver reinstall took care of the problem. Guess I should have tried that a bit sooner.

Thanks for all your help and suggestions.

Jim Dishaw