View previous topic :: View next topic |
Author |
Message |
vtowel n00b
Joined: 28 Jun 2002 Posts: 22 Location: Ontario, Canada
|
Posted: Wed Jul 24, 2002 8:46 pm Post subject: /dev/snd/* permissions always like to change on their own |
|
|
I've had this problem with both systems I've installed Gentoo on.
I've installed KDE 3 and ALSA and these systems (different hardware, though) and generally it works fine. I am part of the 'audio' group and the permissions of /dev/snd are usually as follows:
Code: | crw-rw---- 1 root audio 116, 0 Dec 31 1969 controlC0
crw-rw---- 1 root audio 116, 32 Dec 31 1969 controlC1
crw-rw---- 1 root audio 116, 64 Dec 31 1969 controlC2
etc. |
But now and then I boot into KDE and I hear no sound. I end up finding that it's because the permissions on /dev/snd/* have been set to either this:
Code: | crw------- 1 root audio 116, 0 Dec 31 1969 controlC0
crw------- 1 root audio 116, 32 Dec 31 1969 controlC1
crw------- 1 root audio 116, 64 Dec 31 1969 controlC2
etc. |
or to this:
Code: | crw------- 1 paul root 116, 0 Dec 31 1969 controlC0
crw------- 1 paul root 116, 32 Dec 31 1969 controlC1
crw------- 1 paul root 116, 64 Dec 31 1969 controlC2
etc. |
where 'paul' is my username. In this latter case I wonder why I still don't hear any sound (since I own the devices), but what's even stranger is that the ownership as well as the permissions are changed there. (I swear I didn't touch them!)
I can always fix this problem by sending a HUP to devfsd, but it's a pain to have to do this all the time.
Nobody else in these forums seems to be having this problem, yet Gentoo is the first distro that's exhibited this problem for me and it's happened on both systems I've ever installed it on (with completely different hardware configurations - one's a desktop, the other's a laptop).
Any idea why this could be happening?
As a workaround, is there a way to set up devfs so that it disables changes to any device's ownership or permissions? _________________ cool book |
|
Back to top |
|
|
Naan Yaar Bodhisattva
Joined: 27 Jun 2002 Posts: 1549
|
Posted: Wed Jul 24, 2002 8:49 pm Post subject: |
|
|
I *think* that when I enabled the option that lets the kernel initialize devfs devices upon booting (don't remember exact option), something like this happened to my permissions. I turned it off and there have been no issues since. |
|
Back to top |
|
|
mksoft l33t
Joined: 28 May 2002 Posts: 844
|
Posted: Wed Jul 24, 2002 9:24 pm Post subject: |
|
|
Naan Yaar wrote: | I *think* that when I enabled the option that lets the kernel initialize devfs devices upon booting (don't remember exact option), something like this happened to my permissions. I turned it off and there have been no issues since. |
I have this option enabled here without problems. Seems strange.
vtowel have you changed /etc/devfsd.conf ? _________________ There's someone in my head but it's not me - Pink Floyd |
|
Back to top |
|
|
vtowel n00b
Joined: 28 Jun 2002 Posts: 22 Location: Ontario, Canada
|
Posted: Thu Jul 25, 2002 2:13 pm Post subject: Yes, but not relating to /dev/snd/* |
|
|
Yes, I did make a couple changes to devfsd.conf, but none related to my sound devices. I've included a copy from the system that exhibits this problem the most (my laptop).
Code: | # Sample /etc/devfsd.conf configuration file.
# Richard Gooch <rgooch@atnf.csiro.au> 3-JUL-2000
#
# The Gentoo Linux Team - http://www.gentoo.org/
# - Many fixes, etc
#
# $Header: /home/cvsroot/gentoo-src/rc-scripts/etc/devfsd.conf,v 1.7 2002/05/12 21:48:18 azarah Exp $
# Enable full compatibility mode for old device names. You may comment these
# out if you don't use the old device names. Make sure you know what you're
# doing!
REGISTER .* MKOLDCOMPAT
UNREGISTER .* RMOLDCOMPAT
# You may comment out the above and uncomment the following if you've
# configured your system to use the original "new" devfs names or the really
# new names
#REGISTER vc/.* MKOLDCOMPAT
#UNREGISTER vc/.* RMOLDCOMPAT
#REGISTER pty/.* MKOLDCOMPAT
#UNREGISTER pty/.* RMOLDCOMPAT
#REGISTER misc MKOLDCOMPAT
#UNREGISTER misc RMOLDCOMPAT
# You may comment these out if you don't use the original "new" names
REGISTER .* MKNEWCOMPAT
UNREGISTER .* RMNEWCOMPAT
# Enable module autoloading. You may comment this out if you don't use
# autoloading
LOOKUP .* MODLOAD
# Uncomment the following if you want to set the group to "tty" for the
# pseudo-tty devices. This is necessary so that mesg(1) can later be used to
# enable/disable talk requests and wall(1) messages.
REGISTER ^pty/s.* PERMISSIONS -1.tty 0600
REGISTER ^pts/.* PERMISSIONS -1.tty 0600
# Uncomment this if you want permissions to be saved and restored
# NB: Do NOT change the following!
# Do not do this for pseudo-terminal devices
REGISTER ^pt[sy]/.* IGNORE
CHANGE ^pt[sy]/.* IGNORE
CREATE ^pt[sy]/.* IGNORE
DELETE ^pt[sy] IGNORE
REGISTER .* COPY /lib/dev-state/$devname $devpath
CHANGE .* COPY $devpath /lib/dev-state/$devname
CREATE .* COPY $devpath /lib/dev-state/$devname
DELETE .* CFUNCTION GLOBAL unlink /lib/dev-state/$devname
RESTORE /lib/dev-state
# You can force default like this :
# PERMISSIONS owner_and_group access_mode
# ALSA/OSS stuff
# Comment/change these if you want to change the permissions on
# the audio devices
LOOKUP snd MODLOAD ACTION snd
LOOKUP dsp MODLOAD
LOOKUP mixer MODLOAD
LOOKUP midi MODLOAD
REGISTER sound/.* PERMISSIONS root.audio 660
REGISTER snd/.* PERMISSIONS root.audio 660
# Give the video group write permissions to /dev/dri/*
# This is done to have non root user use the DRM
REGISTER ^dri$ PERMISSIONS root.video 755
REGISTER ^dri/.* PERMISSIONS root.video 660
# Give the cdrw group write permissions to /dev/sg0
# This is done to have non root user use the burner (scan the scsi bus)
REGISTER ^scsi/.*/.*/.*/.*/.* PERMISSIONS root.cdrw 660
# General note for the following auto creation of symlinks:
#
# If you change the device that the symlink points to,
# you should also remove the symlink before restarting
# devfsd
# Create /dev/cdrom for the first cdrom drive
LOOKUP ^cdrom$ CFUNCTION GLOBAL mksymlink cdroms/cdrom0 cdrom
REGISTER ^cdrom/cdrom0$ CFUNCTION GLOBAL mksymlink $devname cdrom
UNREGISTER ^cdrom/cdrom0$ CFUNCTION GLOBAL unlink cdrom
# Create /dev/dvd for the first cdrom drive
# (change 'cdroms/cdrom0' to suite your setup)
LOOKUP ^dvd$ CFUNCTION GLOBAL mksymlink cdroms/cdrom0 dvd
REGISTER ^cdrom/cdrom0$ CFUNCTION GLOBAL mksymlink $devname dvd
UNREGISTER ^cdrom/cdrom0$ CFUNCTION GLOBAL unlink dvd
# Create /dev/cdrw for the first cdrom on the scsi bus
# (change 'sr0' to suite your setup)
LOOKUP ^cdrw$ CFUNCTION GLOBAL mksymlink sr0 cdrw
REGISTER ^sr0$ CFUNCTION GLOBAL mksymlink $devname cdrw
UNREGISTER ^sr0$ CFUNCTION GLOBAL unlink cdrw
# Create /dev/mouse
LOOKUP ^mouse$ CFUNCTION GLOBAL mksymlink misc/psaux mouse
REGISTER ^misc/psaux$ CFUNCTION GLOBAL mksymlink $devname mouse
UNREGISTER ^misc/psaux$ CFUNCTION GLOBAL unlink mouse
# Manage USB mouse
REGISTER ^input/mouse0$ CFUNCTION GLOBAL mksymlink $devname usbmouse
UNREGISTER ^input/mouse0$ CFUNCTION GLOBAL unlink usbmouse
REGISTER ^input/mice$ CFUNCTION GLOBAL mksymlink $devname usbmouse
UNREGISTER ^input/mice$ CFUNCTION GLOBAL unlink usbmouse
# devfsd.conf ends here |
_________________ cool book |
|
Back to top |
|
|
mksoft l33t
Joined: 28 May 2002 Posts: 844
|
Posted: Thu Jul 25, 2002 2:26 pm Post subject: |
|
|
Do you have the same issues with vanilla devfsd.conf _________________ There's someone in my head but it's not me - Pink Floyd |
|
Back to top |
|
|
vtowel n00b
Joined: 28 Jun 2002 Posts: 22 Location: Ontario, Canada
|
Posted: Thu Jul 25, 2002 3:50 pm Post subject: I don't know |
|
|
I don't know if this happens with vanilla devfsd.conf. I guess I can try that then, but it could take up to a week for me to confirm that it works then (this behaviour is pretty erratic). _________________ cool book |
|
Back to top |
|
|
mksoft l33t
Joined: 28 May 2002 Posts: 844
|
Posted: Thu Jul 25, 2002 3:58 pm Post subject: Re: I don't know |
|
|
vtowel wrote: | I don't know if this happens with vanilla devfsd.conf. I guess I can try that then, but it could take up to a week for me to confirm that it works then (this behaviour is pretty erratic). |
We have all the time in the world _________________ There's someone in my head but it's not me - Pink Floyd |
|
Back to top |
|
|
vtowel n00b
Joined: 28 Jun 2002 Posts: 22 Location: Ontario, Canada
|
Posted: Fri Jul 26, 2002 2:52 am Post subject: |
|
|
Well, I'd go ahead and try it but vanilla devfsd.conf doesn't include any dri device entries, and I need proper permissions on those if I want to run X with dri enabled (and I do want that).
Anything else I can try? _________________ cool book |
|
Back to top |
|
|
vtowel n00b
Joined: 28 Jun 2002 Posts: 22 Location: Ontario, Canada
|
Posted: Fri Jul 26, 2002 5:28 am Post subject: |
|
|
This seems to happen in between restarting X. I often have to turn off DRI in X because DRI support for the Radeon on laptops isn't quite ready yet (but it's being improved quickly). So I was using sound just fine in X for a while. Then I logged out of KDE and switched so a virtual console to comment out DRI support in XF86Config. Then I saved it, restarted xdm (kdm), and logged back into KDE.
Upon logging in KDE informed me that arts couldn't grab a hold of the audio device due to permission being denied. It turned out that all my /dev/snd/* and /dev/sound/* devices had changed their ownership to paul.audio and permissions to 0600 (and for some reason I still couldn't access the device, even though I somehow owned it now).
I wonder if this has to do with DRI?
But the strange thing is, I have the exact same behaviour on my Gentoo desktop, which has an nVidia card and uses the proprietary nVidia drivers. It doesn't use DRI (there's nothing in devfsd.conf about DRI on that computer). On my laptop the only difference between my devfsd.conf and the vanilla devfsd.conf is the presence of dri entries to set their permissions appropriately.
I'm using KDE 3.0.1 on my desktop and KDE 3.0.2 on my laptop.
Anything else I should try? _________________ cool book |
|
Back to top |
|
|
vtowel n00b
Joined: 28 Jun 2002 Posts: 22 Location: Ontario, Canada
|
Posted: Tue Jul 30, 2002 1:28 am Post subject: Tip from a DRI guy |
|
|
mksoft,
I don't have time to look into this right now, but after describing my problem to a developer of the DRI drivers (Charl P. Botha), here is what he said:
Quote: | I remember that Redhat used to do this. I can't remember the details, but
there was a configuration file where one could have somewhat more control:
the idea was that the console user would get access to devices like the
sound card without having to be part of the sound group e.g. The
permissions on the devices were actually changed to facilitate this.
|
Maybe you could look into this? These fluctuating permissions and ownerships are starting to drive me nuts. I'm having to kill -HUP 27 at least once a day.
Vanilla devfsd.conf doesn't seem to make a difference.
Thanks,
Paul _________________ cool book |
|
Back to top |
|
|
vtowel n00b
Joined: 28 Jun 2002 Posts: 22 Location: Ontario, Canada
|
Posted: Tue Jul 30, 2002 1:37 am Post subject: |
|
|
Maybe the culprit he's talking about is /etc/security/console.perms? What is that for? _________________ cool book |
|
Back to top |
|
|
HalfFlat n00b
Joined: 30 Jul 2002 Posts: 3
|
Posted: Wed Jul 31, 2002 3:35 am Post subject: |
|
|
As far as I know, it's an interaction between the PAM console permissions support and devfs.
When you login through xdm for the first time, you're given access to all the console devices currently present under /dev, as specified in the console.perms file.
However, something run in your xsession, e.g. a mixer applet, tries to access a sound device which in turn causes some sound module to be loaded which in turn via devfs creates a new device entry under /dev. PAM doesn't get a look in, and that's why there are mixed up permissions.
One solution is to load all the sound modules before xdm starts. Another is to log in through xdm, log out, and then log back in. The ideal solution though would involve running some program that updated console device permissions appropriately as they were created. There are hooks in devfs for this sort of thing, but I haven't looked into it. I also don't know how hard or easy it will be to get PAM to do the hard work.
This last solution would be 'right' though. Not much free time at the moment, so I probably won't do anything about it anytime soon. Anyone feel motivated? |
|
Back to top |
|
|
pjp Administrator
Joined: 16 Apr 2002 Posts: 20067
|
Posted: Fri Aug 09, 2002 5:13 am Post subject: |
|
|
Has any more information been discovered? Maybe a longshot, but is 'File Systems -> '/dev/pts for Unix98 PTYs' enabled in your kernel config? If it is, try disabling it. _________________ Quis separabit? Quo animo? |
|
Back to top |
|
|
vtowel n00b
Joined: 28 Jun 2002 Posts: 22 Location: Ontario, Canada
|
Posted: Fri Aug 09, 2002 5:43 am Post subject: |
|
|
It doesn't seem to be causing a problem much for me anymore. I might be able to reproduce it, but in my dad-to-day tasks I'm not noticing it anymore. I'll let you know if it starts bugging me again. _________________ cool book |
|
Back to top |
|
|
thehyperintelligentslug n00b
Joined: 30 Jun 2002 Posts: 49 Location: Edinburgh
|
Posted: Tue Nov 26, 2002 5:28 pm Post subject: Revive the thread! |
|
|
Hi everybody,
Sorry to 'revive' an old thread but the symptoms described here are exactly like those being experienced by my system and I wonder if anyone has had any 's over the last three or so months?!
I can confirm that:
Quote: | '/dev/pts for Unix98 PTYs' |
is disabled in my kernel config.
Just to clarify, i'm using a 1.4 setup, all up to date and XDM is my display manager but all users use KDE.
Anyone ?
Cheers,
Neil... |
|
Back to top |
|
|
the_bard n00b
Joined: 03 Dec 2002 Posts: 60 Location: Albany, NY
|
Posted: Fri Dec 06, 2002 6:54 am Post subject: Got mine working |
|
|
Talk about reviving an ancient thread...
First off... I'm using Gentoo 1.4rc1, with a Diamond MX300 (aureal 8830 based). I had the sound card modules set up to load on demand.
The problem I was having: The very first time I started X, I could receive no sound due to permission problems. Exit out, and restart X, and it'd work fine. Confused me a bit...
Solution: Simply added the module to /etc/modules.autoload. Now it gets loaded at boot, and the permission problem goes away. Why? I have no clue. I'd like to know why, so I don't have to continuously have the module loaded, but I'll settle for having it work. Besides... what else am I going to use all this memory for? |
|
Back to top |
|
|
turbofish n00b
Joined: 05 Dec 2002 Posts: 8 Location: Sweden
|
Posted: Fri Dec 06, 2002 10:12 am Post subject: same problem |
|
|
Heh, I posted this yesterday. I didn't find this thread while searching the
forums. Silly me. |
|
Back to top |
|
|
thehyperintelligentslug n00b
Joined: 30 Jun 2002 Posts: 49 Location: Edinburgh
|
Posted: Mon Dec 09, 2002 2:59 pm Post subject: |
|
|
Hi,
The problem I am having is that when someone else has been logged in before me and I go to log in it seems they have 'ownership' of the /dev sound entries (and nvidia stuff for that matter);
Code: |
neil@this neil $ cd /dev
neil@this dev $ ls -l | grep andy
crw------- 1 andy video 5, 1 Dec 9 09:02 console
crw------- 1 andy video 195, 0 Jan 1 1970 nvidia0
crw------- 1 andy video 195, 255 Jan 1 1970 nvidiactl
neil@this dev $ ls -l sound
total 0
crw------- 1 andy audio 14, 3 Jan 1 1970 dsp
crw------- 1 andy audio 14, 19 Jan 1 1970 dsp1
crw------- 1 andy audio 14, 2 Jan 1 1970 midi
crw------- 1 andy audio 14, 0 Jan 1 1970 mixer
neil@this dev $
|
[edit]
(By the way, I have no idea what is going on with the dates here).
[/edit]
Cheers,
Neil... |
|
Back to top |
|
|
sekh n00b
Joined: 20 Dec 2002 Posts: 55
|
Posted: Fri Dec 20, 2002 1:48 am Post subject: same prob for me :) |
|
|
Hey there..
I just installed gentoo today.. LOVE it so far great job on making it.
as u've guessed i have the same problem. It doesn't appear to be linked particularily to X for me though. I login in a terminal, and it seems that whomever i login with on the system gets ownership of the files in /dev/sound too on my comp. (I'm using the vanilla sources as suggested above btw).
here's an example:
Code: | peter@linux peter $ ll /dev/sound/
total 0
crw------- 1 peter audio 14, 4 Jan 1 1970 audio
crw------- 1 peter audio 14, 3 Jan 1 1970 dsp
crw------- 1 peter audio 14, 19 Jan 1 1970 dsp1
crw------- 1 peter audio 14, 5 Jan 1 1970 dspW
crw------- 1 peter audio 14, 2 Jan 1 1970 midi
crw------- 1 peter audio 14, 18 Jan 1 1970 midi1
crw------- 1 peter audio 14, 0 Jan 1 1970 mixer
crw------- 1 peter audio 14, 1 Jan 1 1970 sequencer
crw------- 1 peter audio 14, 8 Jan 1 1970 sequencer2
peter@linux peter $ ll /dev/sound/
total 0
crw-rw---- 1 root audio 14, 4 Jan 1 1970 audio
crw-rw---- 1 root audio 14, 3 Jan 1 1970 dsp
crw-rw---- 1 root audio 14, 19 Jan 1 1970 dsp1
crw-rw---- 1 root audio 14, 5 Jan 1 1970 dspW
crw-rw---- 1 root audio 14, 2 Jan 1 1970 midi
crw-rw---- 1 root audio 14, 18 Jan 1 1970 midi1
crw-rw---- 1 root audio 14, 0 Jan 1 1970 mixer
crw-rw---- 1 root audio 14, 1 Jan 1 1970 sequencer
crw-rw---- 1 root audio 14, 8 Jan 1 1970 sequencer2 |
In between those two calls i opened another shell as root an killed devfsd with a -HUP as suggested above. That resets the ownership it seems, but it is a bit annoying to have to do.
Anyone have any ideas?[/code] |
|
Back to top |
|
|
sekh n00b
Joined: 20 Dec 2002 Posts: 55
|
Posted: Sun Dec 22, 2002 4:02 pm Post subject: |
|
|
i found out that it was the pam_console module doing this. Apparently it sets "speciel" permissions on things for users who log in locally. I've commented a few lines out in the /etc/security/console.perms file, and apparently this did the trick. |
|
Back to top |
|
|
pjp Administrator
Joined: 16 Apr 2002 Posts: 20067
|
Posted: Sun Dec 22, 2002 6:53 pm Post subject: |
|
|
Moved from OTG. _________________ Quis separabit? Quo animo? |
|
Back to top |
|
|
|