Hi All,

I need to set permissions on /dev/dsp to allow a 2nd user to logon to the same PC and also gain access to the soundcard. Running chmod 660 /dev/dsp0 works -- but, like most distros, SuSE 9.1 resets permissions on devices upon rebooting.

I've edited /etc/permissions and /etc/permissions.local to read:

(In doing this, I've had to assign owner ship to my account, but I can live with this -- so long as my wife belongs to the audio group and permissions are set to 660, it all works out in the end.)

However this doesn't really solve the problem. When I reboot, the permissions are reset -- I need to run SuSEConfig as root before the permissions.local file kicks in and changes the permissions to 660.

Mandrake uses a similar system, but with the console.perms file -- but at least Mandrake checked this file upon booting and set permissions accordingly. How can I get SuSE to either keep my permissions or set /dev/dsp to 660 upon bootup?

I cannot, for the life of me, sort this one out. It's probably really simple, but ANY help is appreciated.

Cheers,
Tim

Write the command to change the permissions in a script and add it to the boot process.

In SuSE you have 3 security levels, which detremine what permissions.* file is executed.
easy, secure and paranoid.

So you have permissions.easy , permissions.secure and permissions.paranoid files under /etc

You can set the security level via YAST -> Security and Users -> Security Settings

Select one Preset Level (1,2,3 or custom) and then click on the " next" button. REMARK: Those presets are *not* the security levels I metioned above. You will be then guided through several dialogs, where
you can change settings. After changing the settings in one dialog click on the next "Button".

The Dialog Order is: Password Settings -> Boot Settings -> Login Settings -> Adding User -> Miscellaneous Settings

In Miscellaneous Settings you can change the security level (easy, secure or paranoid). Do not forget to
edit the corresponding permissions.* file.

Hi Vlad-A,

Thanks for the suggestion -- I really appreciate the input!

In the end, I set my security level to easy, and edited the permissions.easy file. Rebooted, and no effect -- /dev/dsp was still 0600.

For some reason, though, your suggestion gave me a bit of an epiphany. I did a search for the term "/dev/dsp" in the /etc/ directory to see what files in there including that string. It turns out there's a file called "/etc/logindevperm" that sets all the /dev/ permissions upon login.

(I feel like I bit of a wally -- just look at the name of the file: logindevperm. Kinda says it all!!)

Anyway, there's a bunch of instructions in there that look like this:

So I just changed the 0600 to 0660. Now when the first user logs in, the file is set to allow the Audio group access to /dev/dsp regardless of who the owner of the device is. PROBLEM SOLVED!

Thanks again!

Tim

I am just curious: Why do you need rw access to the dsp device for other users then root ?

Hey Vlad,

>I am just curious: Why do you need rw access to the dsp device for other users then root ?

Unless all users have at read access to /dev/dsp, only the first person to login will get access to the sound card -- otherwise, the first person has sound, but no one else does.

It's just the way the distro works, I suppose. Mandrake and SuSE -- and probably a lot of other distros -- work this way as well. For example, if I login to my box (my default session is KDE), then SuSE allocates permissions to /dev/dsp, making me the owner, and "audio" the group. But it also forbids access to /dev/dsp to "group" and "other". When my wife then logs in (ie, in ctrl+F8 -- you know what I mean), then the system determines that I own the device /dev/dsp, and she can't access it, even though she belongs to the group "audio". Thus, her account is mute.

Now, whether or not she needs write access as well as read access, I don't really know. But it's easier to give her read/write access, so that her account does everything that mine does. And, of course, on rare occasions she logs in first, thus "inheriting" /dev/dsp and locking me out unless permissions are reset.

For some reason, I've found that both Mandrake and SuSE fail to allow multiple users to gain access to /dev/dsp. Both require mucking about in config files (like console.perms or permission.local) before they will allow multiple users to coexist happily.

Tim

I do not know if I exactly understand. I have 2 users on my system (let's call them user1 and user2) + root user.

When I log in into KDE as user1 and ls -l /dev |grep dsp
then /dev/dsp0 belongs to user1 and group audio.
Permissions are: 600 (so user1 has read/write access to the audio card)

Now I log out and log in into KDE as user2
Again ls -l /dev|grep dsp
/dev/dsp0 belongs to user2 and group audio.
Permissions are: 600 (so user2 has read/write access to the audio card)

The same when I log in as root. /dev/dsp belongs to root and audio.

So every time a user logs in the ownership of /dev/dsp0 is changed to that user.

I am using SuSE, and did not change *anything* on any permission, etc, so left the files as they
are at installation time.

This is how SuSE works, at least my installation and that's how it worked since I am using SuSE.

On log in ownership of the sound device spec. file is changed to the user. When a new user logs-in
ownership is changed to the new user.

So when you log in of course the device belongs to you. When, however, your wife logs-in, the system should
change ownership of /dev/dsp0 to the account of your wife independent whether anyone was previously loged in or not.

In Mandrake, I've noticed that the regular security check (msec) only ever increases the permissions level., i.e. it only tightens security. If you set up a list of exceptions (perm.local), msec will ignore any entries that loosen security. (It would have been nice if the draksec utility recognized this, rather than forced users to figure things out by trial and error. Unfortunately, poor documentation is very typical of Mandrake.)

I've found two ways around this issue. (1) Instead of executing 'msec', execute 'msec n' where n is the security level. This option enables msec to downgrade permissions. (2) Use a lower security level than you need and then tighten the security options manually.

George

Hey Vlad,

I'm glad you brought this up, because this is really interesting...

See, this doesn't happened on my box -- I've run SuSE, Mandrake and Fedora Core 2 (briefly) on this particular box, and in all cases /dev/dsp has been allocated to the user1, so that user2 isn't able to use sound when they log on. In the case of Mandrake, it would actually pop up an error about being unable to access /dev/dsp when user2 first logged in. SuSE doesn't do this -- it just doesn't play sound of any sort.

I've always just assumed that this was an error with the distro, and always wondered why there wasn't more documentation about how to fix it. Maybe it's a hardware issue? (I have a SB Live! Value card) I know that on my last computer -- it was an old clunker, and I ran SuSE 8.2 then Mandrake 9.0 with an old SB16 card -- this problem didn't occur. On this box with an SB Live!, Mandrake 9.2, Mandrake 10.0, Fedora Core 2, and SuSE 9.1 have all tripped up on it.

Cheers,
Tim

Hi George,

Have you tried editing /etc/security/console.perms? This is what I did with Mandrake 9.2 and 10.0, and it allowed me to refine permissions without touching any other msec commands.

RE the above issue, in Mandrake it was as simple as altering one line in /etc/security/console.perm to read:

I tried wrestling with msec and security options, but this the was the easiest option. Every boot it set the permissions as defined by this file.

Cheers,
Tim

Just want you to know that this solved the exact problem I was having! I renamed several of those items to 660 and now my second user account works with the sound card and the mixer/volume control shows up (which it didn't).

I think I can finally do everything I need to do with Linux (after installing and spending a week on the printer...it was BIOS switch).

Thanks all for the forum and help!