Guest cid Posted February 17, 2003 Report Share Posted February 17, 2003 Is this a common problem? If I do ctrl-alt-f1, then use the startx command to start a second session, i get an error that the sound device is not usable. Any ideas? Or is this just a known limitation. It almost seems as if there is some kind of prevention of sharing from the sound device that won't let this happen. Works fine in WindowsXP fast user switching environments, both users have sound fine. In xandros fast user switching GUI, it also seems to work. Thanks in advance! D Quote Link to comment Share on other sites More sharing options...
pmpatrick Posted February 17, 2003 Report Share Posted February 17, 2003 Works fine on my box. Out of curiosity I did fiddle around a bit and discovered that if I left an mp3 playing in xmms and started a second X session, I could still hear the mp3 from the first session playing(could also hear it playing from the login screen for the second session). Got an error message in the second session that /dev/dsp was unavailable, ect. However, sound still worked in the second session. Although I could not open xmms in the second session, I could play an mp3 on noatun. It was kind of wierd having them both play simultaneously but they both were playing and other system sounds would play as well in the second session. Haven't thought through the ramifications of all this but it appears on my system that once some program grabs the sound server it doesn't let go even when switching to a second X session. Quote Link to comment Share on other sites More sharing options...
mdg Posted February 17, 2003 Report Share Posted February 17, 2003 Sometimes right after bootup into Mdk, if I start xmms, I get an error that the device is not available. If I try a minute or two later, it works. Don't know what the cause is Quote Link to comment Share on other sites More sharing options...
mtweidmann Posted February 17, 2003 Report Share Posted February 17, 2003 I guess it'll be because of the sound card drivers. Essentially only one thing can use the sound card at any one time. If you already have something like arts running, and then try to run another none arts app that wants the sound card it probably won't work. Windows acts as a middle man to all the apps that want access to the sound card. KDE has a similar system (arts) that agian acts as a middle man. Otherwsie in Linux its normally a first come first served system. Quote Link to comment Share on other sites More sharing options...
aru Posted February 17, 2003 Report Share Posted February 17, 2003 I guess it'll be because of the sound card drivers. Essentially only one thing can use the sound card at any one time. Not because one thing can use the sound card at any time, but because an user "owns" the card each time: arusabal@hostname ~$ ls -l /dev/sound/ total 0 crw------- 1 arusabal audio 14, 4 ene 1 1970 audio crw------- 1 arusabal audio 14, 3 ene 1 1970 dsp crw------- 1 arusabal audio 14, 5 ene 1 1970 dspW crw------- 1 arusabal audio 14, 0 ene 1 1970 mixer crw------- 1 arusabal audio 14, 1 ene 1 1970 sequencer crw------- 1 arusabal audio 14, 8 ene 1 1970 sequencer2 I can open as many login sessions as I want with the same user and I can play music from any of them. The trouble comes when I login as another user. If I want to play music from a second user account, while the "card is owned" by a 'first user', I have to su as root and chown the card device files to the second user. Then the second user is allowed to play music. This is a security feature (which has little sense in stand alone machines). That is at least true for devfsd 1.3.18 Quote Link to comment Share on other sites More sharing options...
Guest cid Posted February 17, 2003 Report Share Posted February 17, 2003 Great Aru! So as I work on my GUI user switching (or at least scripted user switching)... That's one thing I can add as the user logs in: su -c chown $user1:/dev/sound/ Or something like that... D Quote Link to comment Share on other sites More sharing options...
Guest ndeb Posted February 18, 2003 Report Share Posted February 18, 2003 If I want to play music from a second user account, while the "card is owned" by a 'first user', I have to su as root and chown the card device files to the second user. Then the second user is allowed to play music. This is a security feature (which has little sense in stand alone machines). Thanks for catching this. But how is this a security feature ? Shouldn't these files and directories be owned by the root as in: crw-rw-rw- 1 root audio 14, 4 ene 1 1970 audio crw-rw-rw- 1 root audio 14, 3 ene 1 1970 dsp crw-rw-rw- 1 root audio 14, 5 ene 1 1970 dspW crw-rw-rw- 1 root audio 14, 0 ene 1 1970 mixer crw-rw-rw- 1 root audio 14, 1 ene 1 1970 sequencer crw-rw-rw- 1 root audio 14, 8 ene 1 1970 sequencer2 Other device files are always owned by root. This is in fact, a bug that allows one non-root user to prevent others from accessing a device. Quote Link to comment Share on other sites More sharing options...
aru Posted February 18, 2003 Report Share Posted February 18, 2003 Don't you think that it will be dangerous/stupid to networked machines to allow "others" read-write access to the audio device as are shown in your ls output. Remember that linux is meant to be a free substitue of Unix, not a substitute of M$windows for the desktop. For example, why would want one user connected remotely play music on a local machine? There are more concerns about this, but just don't remember them :) What was typical, or at least that is what I used to do before the "devfs" (kernels 2.2.x) was to let root to own the sound card device files, and add users to the sound group. Then grant rw permissions to both owner and group. This before the "devfs" was as simple as changing permissions. But now If you really need to allow several users to access the sound card, at the "same" time you'll need to configure the devfs as follows: a) Add every user who needs to access the sound card to the group sound (editing /etc/group) B) Edit /etc/devfsd.conf to append something like this: "REGISTER sound/.* PERMISSIONS root.audio rw-rw----"; that will grant group read-writte permissions to the sound device files. So from this moment devfsd on boot will create the device files acordingly to your settings. BE CAREFUL, because messing with devfsd.conf might make your system unbootable (so have at hand a copy of the resque cdrom). c) Restart the devfs daemon: "killall -HUP devfsd" d) test it! HTH Quote Link to comment Share on other sites More sharing options...
Guest ndeb Posted February 18, 2003 Report Share Posted February 18, 2003 Don't you think that it will be dangerous/stupid to networked machines to allow "others" read-write access to the audio device as are shown in your ls output. Remember that linux is meant to be a free substitue of Unix, not a substitute of M$windows for the desktop. For example, why would want one user connected remotely play music on a local machine? There are more concerns about this, but just don't remember themWhy would it be any less dangerous to make it owned by a non-root user ? Other device files are not owned by non-root. Also, if I am the non-root user owner of the device files, I can always login from a remote machine and access them and prevent the local non-root user from accessing it. What if I chose to delete them all ? Thats DOS !! If the device files are owned by root, then no non-root user can delete them. If u do not want a remote user to access the sound device, there are much better ways of doing it. For example, u cannot directly start X from a remote login using startx because it checks if u have logged in locally or remotely. I have seen fully networked linux machines in production environments where audio device files are owned by root:audio (crw-rw-rw-) and thats for security, not against it. Quote Link to comment Share on other sites More sharing options...
aru Posted February 18, 2003 Report Share Posted February 18, 2003 Why would it be any less dangerous to make it owned by a non-root user ? Other device files are not owned by non-root. Also, if I am the non-root user owner of the device files, I can always login from a remote machine and access them and prevent the local non-root user from accessing it. What if I chose to delete them all ? Thats DOS !! If the device files are owned by root, then no non-root user can delete them.Sorry, but I think I don't follow you here. Where did I say that it would be safer to make a device owned by a non-root user? I said that is silly to allow "others" read-write permission ('other' as in owner,group,OTHERS). And from your "ls -l" output, what I see is that you allow 'others' read-write permisions to your sound device files, which is really wrong. In my example on how to configure the devfsd, the sound device files are owned by root and belong to sound group. Read-write permissions are granted for owner and group, but not for others. Users have to become part of the sound group in order to play music. In my first post, the sound device is owned by the user who is logs-in at first because of the particular behavior of mandrake (the thing works as you can check in your /etc/devfsd.conf at the line related to sound (check the man page of pam_console_apply for more info)). This happens in my Mdk machine, but not in my slack which is configured as I showed you in my last post. If u do not want a remote user to access the sound device, there are much better ways of doing it. For example, u cannot directly start X from a remote login using startx because it checks if u have logged in locally or remotely. Does it apply to every situation? to every single case? I can run graphical apps remotely. and what if I login using other ways. I've just tested it, I can play music if I'm loged-in from my slackware machine in my Mdk one If I allow others rw permissions. What would be easier? think of every single way to access a device and protect it, or just simply not allow untrusted users to use it. As I said above it has security concerns, far away from simply allowing users to play music in a networked machine, but, again, I don't remember them, maybe you'll want to do a google check. Quote Link to comment Share on other sites More sharing options...
Guest ndeb Posted February 19, 2003 Report Share Posted February 19, 2003 Sorry, but I think I don't follow you here. Where did I say that it would be safer to make a device owned by a non-root user? I said that is silly to allow "others" read-write permission ('other' as in owner,group,OTHERS). And from your "ls -l" output, what I see is that you allow 'others' read-write permisions to your sound device files, which is really wrong. In my example on how to configure the devfsd, the sound device files are owned by root and belong to sound group. Read-write permissions are granted for owner and group, but not for others. Users have to become part of the sound group in order to play music. Ok, u meant others as in user:group:others. In that case u r indeed right. It is wiser to keep the owner as root (which is not the case currently) and have permissions like crw-rw----, allowing only users in the audio group to access the sound device. That seems to be the best solution. In fact, cdrecord/xcdroast uses a similar approach which allows non-root users belonging to group cdwriter to burn cds. Does it apply to every situation? to every single case? I can run graphical apps remotely. Only graphical apps that use ur local X. Not the same as running X remotely. But vncserver allows that in some sense and thats why running it over an ssh tunnel is recommended. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.