Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Device Permissions: Group Membership

32 views
Skip to first unread message

Douglas Mayne

unread,
Feb 3, 2012, 4:09:48 PM2/3/12
to
I just noticed that on version 13.37 of Slackware the individual user
doesn't have to be a member of the audio group to use the sound devices.
The same goes for the user not having to be a member of the video group
to use webcams, etc. In a way it makes more sense for the user to have
to be given explicit permission. What changed that makes it possible
to /* just work */ without requiring tweaks to the /etc/group file?

The permissions to /dev/dsp look like this:

$ ls -la /dev/dsp1
crw-rw----+ 1 root audio 14, 19 Feb 3 09:39 /dev/dsp1

Thanks in advance for any help shedding some light on this!


By the way, I ran into this problem while trying to debug why a new
user couldn't play audio files remotely using ssh. These error
messages were a bit cryptic, but google helped to decode that
it was a permissions problem, and not some environment variable
or other edge case.

ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:3985:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2202:(snd_pcm_open_noupdate) Unknown PCM default
sox FAIL formats: can't open output file `default': snd_pcm_open error: No such file or directory

--
Douglas Mayne

Kees Theunissen

unread,
Feb 3, 2012, 5:28:56 PM2/3/12
to
Douglas Mayne wrote:
> I just noticed that on version 13.37 of Slackware the individual user
> doesn't have to be a member of the audio group to use the sound devices.
> The same goes for the user not having to be a member of the video group
> to use webcams, etc. In a way it makes more sense for the user to have
> to be given explicit permission. What changed that makes it possible
> to /* just work */ without requiring tweaks to the /etc/group file?
>
> The permissions to /dev/dsp look like this:
>
> $ ls -la /dev/dsp1
> crw-rw----+ 1 root audio 14, 19 Feb 3 09:39 /dev/dsp1
>
> Thanks in advance for any help shedding some light on this!

Have a look at /etc/login.defs:

[...]
# List of groups to add to the user's supplementary group set
# when logging in on the console (as determined by the CONSOLE
# setting). Default is none.
#
# Use with caution - it is possible for users to gain permanent
# access to these groups, even when not logged in on the console.
# How to do it is left as an exercise for the reader...
#
# Most of these groups are self-explanatory.
#
# Note that users are added to these default groups only when
# logging into a shell with /bin/login, not when using a login
# manager such as kdm. In that case, users who should have
# hardware access must be added to the appropriate groups
# when the user is added with adduser or useradd, or by editing
# /etc/group directly, preferably using "vigr"
#
CONSOLE_GROUPS floppy:audio:cdrom:video:scanner
[...]


I suppose you're running in the default runlevel 3 and users
log in on a virtual console, not with kdm/xdm.


> By the way, I ran into this problem while trying to debug why a new
> user couldn't play audio files remotely using ssh. These error
> messages were a bit cryptic, but google helped to decode that
> it was a permissions problem, and not some environment variable
> or other edge case.
>
> ALSA lib confmisc.c:768:(parse_card) cannot find card '0'
> ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
> ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
> ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
> ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
> ALSA lib conf.c:3513:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
> ALSA lib conf.c:3985:(snd_config_expand) Evaluate error: No such file or directory
> ALSA lib pcm.c:2202:(snd_pcm_open_noupdate) Unknown PCM default
> sox FAIL formats: can't open output file `default': snd_pcm_open error: No such file or directory
>


Regards,

Kees.

--
Kees Theunissen.

Mikhail Zotov

unread,
Feb 5, 2012, 7:19:37 AM2/5/12
to
On Fri, 3 Feb 2012 21:09:48 +0000 (UTC)
Douglas Mayne <no...@invalid.com> wrote:

> I just noticed that on version 13.37 of Slackware the individual user
> doesn't have to be a member of the audio group to use the sound
> devices.

On my machine, this isn't the case. To test, I created a `fake' group
and a `fake' user belonging to that group only. "id fake" displayed
that user `fake' is the member of a single group (`fake'). Then I ran
"su - fake" as superuser.

An attempt to play an mp3 file didn't work: I got a list of
messages similar to those you posted. Adding `fake' to the audio
group fixed the problem immediately.

In a similar fashion, `fake' was unable to eject a CD-tray and perform
some other things until I added `him' to an appropriate group.

Regards,
Mikhail

Douglas Mayne

unread,
Feb 6, 2012, 11:31:05 AM2/6/12
to
After looking closer, I also verified the same behavior you describe. My
initial conclusions were wrong- sorry about any confusion. I agree with
Kees response that pinpointed the problem being due to the method that a
user has logged in, and whether the "console groups" as defined by
login.defs has been applied. Apparently it is not applied under certain
circumstances. You mention su, and I see the same thing when logging in
using ssh. It makes sense to explicitly give users permission to use
specific devices (audio,video,cdrom and others) as desired, and that is
true under all versions of slackware that I tested. I use ssh so often I
think of it as a defacto console, but it's really a remote protocol and
can be given less permissions, etc.

--
Douglas Mayne
0 new messages