Audiozugriff für andere Benutzer freigeben?
Hallo, Audio funktioniert gut unter einem Benutzer und unter root, aber alle anderen Benutzer können nicht darauf zugreifen. Was muss ich tun um den Zugriff für andere Benutzer freizugeben? Gruss Karl
Am Sonntag, 18. Dezember 2005 14:19 schrieb Karl:
Audio funktioniert gut unter einem Benutzer und unter root, aber alle anderen Benutzer können nicht darauf zugreifen.
Was muss ich tun um den Zugriff für andere Benutzer freizugeben?
Ich mache das, wenn ich es mal brauche, immer händisch mit chmod g+rw /dev/snd/* Das wird aber AFAIK nur bis zum nächsten Login (auf dem ersten X-Server, also :0, siehe unten!) helfen, weil die Gruppenrechte von pam_devperm anhand /etc/logindevperm wieder entfernt werden. Sprich, in /etc/logindevperm diese Zeile :0 0600 /dev/snd/* durch diese :0 0660 /dev/snd/* ^ ersetzen. Näheres dazu in u.a. "man logindevperm". Wichtig: Paralleler Audiozugriff geht nur wenn die Soundkarte das kann oder man das dmix-Plugin für ALSA benutzt und letzterem auch die richtigen Rechte für seine Interprozeßkommunikation. Bei mir geht das so, im Abschnitt für dmix in /etc/asound.conf die Zeile "ipc_perm 0660" hinzufügen: type dmix ipc_key 1024 ipc_perm 0660 HTH Jan -- Habit is stronger than reason.
Hallo Jan, Danke für die schnelle Antwort. Am Sonntag, 18. Dezember 2005 14:42 schrieb Jan Ritzerfeld:
Das wird aber AFAIK nur bis zum nächsten Login (auf dem ersten X-Server, also :0, siehe unten!) helfen, weil die Gruppenrechte von pam_devperm anhand /etc/logindevperm wieder entfernt werden. Sprich, in /etc/logindevperm diese Zeile
:0 0600 /dev/snd/*
durch diese
:0 0660 /dev/snd/*
Ich habe mir die /etc/logindevperm mal angeschaut, und festgestellt dass alle Geräte auf 0600 gesetzt werden. Und mit cdrom und dvd funktioniert das einwandfrei. Warum muss ich das für den Sound ändern?
Wichtig: Paralleler Audiozugriff geht nur wenn die Soundkarte das kann oder man das dmix-Plugin für ALSA benutzt und letzterem auch die richtigen Rechte für seine Interprozeßkommunikation. Bei mir geht das so, im Abschnitt für dmix in /etc/asound.conf die Zeile "ipc_perm 0660" hinzufügen: type dmix ipc_key 1024 ipc_perm 0660
Die /etc/asound.conf gibt es bei mir nicht. Ich weiss dass meine Soundkarte keinen parallelen Zugriff kann, allerdings funktioniert es gleichzeitig als user root und als user Karl. Das bedeutet doch eigentlich dass der mixer dmix automatisch benutzt wird, oder? Gruss Karl
Am Sonntag, 18. Dezember 2005 16:10 schrieb Karl:
Hallo Jan,
Danke für die schnelle Antwort.
Am Sonntag, 18. Dezember 2005 14:42 schrieb Jan Ritzerfeld:
Das wird aber AFAIK nur bis zum nächsten Login (auf dem ersten X-Server, also :0, siehe unten!) helfen, weil die Gruppenrechte von pam_devperm anhand /etc/logindevperm wieder entfernt werden. Sprich, in /etc/logindevperm diese Zeile
:0 0600 /dev/snd/*
durch diese
:0 0660 /dev/snd/*
Ich habe mir die /etc/logindevperm mal angeschaut, und festgestellt dass alle Geräte auf 0600 gesetzt werden. Und mit cdrom und dvd funktioniert das einwandfrei. Warum muss ich das für den Sound ändern?
Hallo Karl, die 0600 sorgt dafür das nur der Benutzer Zugriff auf das entsprechende device hat der als erstes darauf Zugriff genommen hat. Wenn also zwei Benutzer gleichzeitig angemeldet sind hat nur derjenige Zugriff auf die verschiedenen Soundkomponenten der als erstes angemeldet wurde. Bei CD/DVD mag das nicht so zum tragen kommen, bei Sound jedoch schon. Grundsätzlich wäre jetzt allerdings zu klären ob es bei Dir überhaupt darum geht das zwei Benutzer gleichzeitig angemeldet Zugriff auf Sound haben, oder ob grundsätzlich nur ein Benutzer Sound hat, und die anderen nicht (auch wenn kein anderer angemeldet ist). Wenn es darum geht mehreren Benutzern gleichzeitig den Zugriff zu ermöglichen solltest Du, wie schon beschrieben, in der /etc/logindevperm die Werte für /dev/dsp0:/dev/dsp1:/dev/dsp2:/dev/dsp3 /dev/audio:/dev/audio0:/dev/audio1:/dev/audio2:/dev/audio3:/dev/audioctl /dev/mixer0:/dev/mixer1:/dev/mixer2:/dev/mixer3 /dev/snd/* von 0600 auf 0660 setzen. Wenn jedoch die anderen Benutzer grundsätzlich, also auch wenn sie alleine angemeldet sind, keinen Sound haben bzw der artsd abstürzt, dann liegt das Problem wohl woanders. Sag doch noch mal Bescheid Micha
Am Sonntag, 18. Dezember 2005 16:10 schrieb Karl:
Hallo Jan,
Danke für die schnelle Antwort.
Am Sonntag, 18. Dezember 2005 14:42 schrieb Jan Ritzerfeld:
Das wird aber AFAIK nur bis zum nächsten Login (auf dem ersten X-Server, also :0, siehe unten!) helfen, weil die Gruppenrechte von pam_devperm anhand /etc/logindevperm wieder entfernt werden. Sprich, in /etc/logindevperm diese Zeile
:0 0600 /dev/snd/*
durch diese
:0 0660 /dev/snd/*
Ich habe mir die /etc/logindevperm mal angeschaut, und festgestellt dass alle Geräte auf 0600 gesetzt werden. Und mit cdrom und dvd funktioniert das einwandfrei. Warum muss ich das für den Sound ändern?
Du mußt zwischen dem direkten Zugriff und dem Zugriff auf ein Dateisystem unterscheiden. Letzteres geht über /etc/fstab und auch nur, wenn das Benutzern auch erlaubt ist, durch die Option "user". Um Video-DVDs ansehen zu können, mußt du allerdings auch die Rechte auf das entsprechende Device direkt haben.
Wichtig: Paralleler Audiozugriff geht nur wenn die Soundkarte das kann oder man das dmix-Plugin für ALSA benutzt und letzterem auch die richtigen Rechte für seine Interprozeßkommunikation. Bei mir geht das so, im Abschnitt für dmix in /etc/asound.conf die Zeile "ipc_perm 0660" hinzufügen: type dmix ipc_key 1024 ipc_perm 0660
Die /etc/asound.conf gibt es bei mir nicht. Ich weiss dass meine Soundkarte keinen parallelen Zugriff kann, allerdings funktioniert es gleichzeitig als user root und als user Karl.
Wenn Karl sich zuerst eingelogt, hat er die passenden Rechte. Root sind die Rechte ja eh egal. Daher klappt das so auch ohne besondere Gruppenrechte für die ALSA-Device-Nodes.
Das bedeutet doch eigentlich dass der mixer dmix automatisch benutzt wird, oder?
Das kann gut sein, neuere ALSA-Versionen haben dmix direkt aktiviert. Vielleicht sogar auch mit korrekten IPC-Rechten. Die Dateien /tmp/alsa-dmix-* müssen 0660 als Rechte haben (also sowas wie srw-rw----). Gruß Jan -- The brighter the smile the sharper the knife.
Hallo, Am Sonntag, 18. Dezember 2005 14:42 schrieb Jan Ritzerfeld:
Ich mache das, wenn ich es mal brauche, immer händisch mit chmod g+rw /dev/snd/*
Habe ich ausprobiert, aber es funktioniert nicht. Der artsd stürzt beim starten der Session immer noch ab. Kann das Problem eventuell irgendwo anders liegen? Wo kann ich nachschauen? In /var/log/messages ist nichts zu finden! Gruss Karl
Am Sonntag, 18. Dezember 2005 16:58 schrieb Karl:
Hallo,
Am Sonntag, 18. Dezember 2005 14:42 schrieb Jan Ritzerfeld:
Ich mache das, wenn ich es mal brauche, immer händisch mit chmod g+rw /dev/snd/*
Habe ich ausprobiert, aber es funktioniert nicht.
Aber du benutzt schon ALSA? :)
Der artsd stürzt beim starten der Session immer noch ab.
Hui. Das hatte ich aus deiner ursprünglichen Nachricht gar nicht entnehmen können.
Kann das Problem eventuell irgendwo anders liegen?
Okay. Gehn wir da mal systematisch ran: Unter welchen Benutzern und Umständen kannst du überhaupt etwas mit dem Befehl aplay abspielen (z. B. WAV-Dateien)?
Wo kann ich nachschauen? In /var/log/messages ist nichts zu finden!
Da fällt mir spontan ~/.xsession-errors ein. Wenn der artsd abgestürzt ist kannst du mal versuchen ihn von der Konsole aus zu starten (eben mit artsd), dann siehst du die Fehlermeldungen direkt. Gruß Jan -- A statistician is a person who draws a mathematically precise line from an unwarranted assumption to a forgone conclusion.
Hallo, Am Montag, 19. Dezember 2005 22:17 schrieb Jan Ritzerfeld:
Aber du benutzt schon ALSA? :)
Ich denke schon :-) Wie kann ich da sicher sein?
Der artsd stürzt beim starten der Session immer noch ab.
Hui. Das hatte ich aus deiner ursprünglichen Nachricht gar nicht entnehmen können.
Kann das Problem eventuell irgendwo anders liegen?
Okay. Gehn wir da mal systematisch ran: Unter welchen Benutzern und Umständen kannst du überhaupt etwas mit dem Befehl aplay abspielen (z. B. WAV-Dateien)?
Habe ich getestet, führt zu genau dem gleichen Ergebnis: Karl und root kann, aber alle anderen nicht Ich habe versucht artsd als einer der anderen user zu starten funktioniert nicht mangels Zugriffsrechte auf /dev/dsp was wiederum auf /dev/dsp0 verweisst, und dort ist als user der user Karl eingetragen.
Wo kann ich nachschauen? In /var/log/messages ist nichts zu finden!
Da fällt mir spontan ~/.xsession-errors ein. Wenn der artsd abgestürzt ist kannst du mal versuchen ihn von der Konsole aus zu starten (eben mit artsd), dann siehst du die Fehlermeldungen direkt.
Da steht was mit cannot find card '0' OK, das sieht alles nach einem Zugriffsproblem aus. Ich habe versucht wie in Deiner ersten Fehlerlösung in der Datei /etc/... alles auf 0660 zu setzten, und neustarten, hat aber keine Änderung gebracht. Gruss Karl
Am Freitag, 23. Dezember 2005 19:07 schrieb Karl:
Hallo,
Am Montag, 19. Dezember 2005 22:17 schrieb Jan Ritzerfeld:
Aber du benutzt schon ALSA? :)
Ich denke schon :-) Wie kann ich da sicher sein?
Unter Karl oder root (halt bei den Benutzern mit funktionierendem artsd): jan@linux:~> artsshell status | grep "audio method:" audio method: alsa
Der artsd stürzt beim starten der Session immer noch ab.
Hui. Das hatte ich aus deiner ursprünglichen Nachricht gar nicht entnehmen können.
Kann das Problem eventuell irgendwo anders liegen?
Okay. Gehn wir da mal systematisch ran: Unter welchen Benutzern und Umständen kannst du überhaupt etwas mit dem Befehl aplay abspielen (z. B. WAV-Dateien)?
Habe ich getestet, führt zu genau dem gleichen Ergebnis: Karl und root kann, aber alle anderen nicht
Okay. Dann liegt das Problem grundsätzlich wohl eher bei ALSA als beim artsd (auch wenn der artsd nicht abstürzen sollte).
Ich habe versucht artsd als einer der anderen user zu starten funktioniert nicht mangels Zugriffsrechte auf /dev/dsp was wiederum auf /dev/dsp0 verweisst, und dort ist als user der user Karl eingetragen.
/dev/dsp ist nicht wirklich alsa sondern entweder OSS oder ALSAs OSS Emulation. Du wirst den artsd wohl auf "automatik" gestellt haben, da sucht der natürlich nach verschiedenen Soundsystemen und scheint als letztes OSS zu probieren. Also, wenn ich unter einem anderen Benutzer, der keine ausreichenden Rechte an den Dateien in /dev/snd/ besitzt, artsd von einer Konsole starte kommt wohl die gleiche Fehlermeldung wie bei dir: tv@linux:~> artsd Error while initializing the sound driver: device /dev/dsp can't be opened (Permission denied) Bist du dir sicher, daß deine anderen Benutzer in der Gruppe "audio" sind und diese Gruppe Schreib- und Leserechte auf die Dateien in /dev/snd/ haben? Wie eben in diesem Thread aber einem anderen Artikel von mir beschrieben klappt das alles auch ohne viel Bastelei an den Rechten: Der artsd startet und ich kann unter diesem Benutzer problemlos mit bspw. "artsplay" WAV-Dateien abspielen.
Wo kann ich nachschauen? In /var/log/messages ist nichts zu finden!
Da fällt mir spontan ~/.xsession-errors ein. Wenn der artsd abgestürzt ist kannst du mal versuchen ihn von der Konsole aus zu starten (eben mit artsd), dann siehst du die Fehlermeldungen direkt.
Da steht was mit cannot find card '0'
In Zusammenhang mit kmix?
OK, das sieht alles nach einem Zugriffsproblem aus.
Ich habe versucht wie in Deiner ersten Fehlerlösung in der Datei /etc/... alles auf 0660 zu setzten, und neustarten, hat aber keine Änderung gebracht.
S.o.: "Bist du dir sicher, daß deine anderen Benutzer ..." Gruß Jan -- The final test of a gentleman is his respect for those who can be of no possible use to him.
Hallo Jan, Am Freitag, 23. Dezember 2005 20:41 schrieb Jan Ritzerfeld:
Unter Karl oder root (halt bei den Benutzern mit funktionierendem artsd): jan@linux:~> artsshell status | grep "audio method:" audio method: alsa
Karl@linux:~> artsshell status | grep "audio method:" unix_connect: can't connect to server (unix:/tmp/ksocket-Karl/linux.site-261d-43ac9917) unable to connect to sound server
Bist du dir sicher, daß deine anderen Benutzer in der Gruppe "audio" sind und diese Gruppe Schreib- und Leserechte auf die Dateien in /dev/snd/ haben?
Die sind alle so angelegt: crw-rw---- 1 Karl audio 116, 0 2005-03-19 20:36 controlC0
Wie eben in diesem Thread aber einem anderen Artikel von mir beschrieben klappt das alles auch ohne viel Bastelei an den Rechten: Der artsd startet und ich kann unter diesem Benutzer problemlos mit bspw. "artsplay" WAV-Dateien abspielen.
Wo kann ich nachschauen? In /var/log/messages ist nichts zu finden!
Da fällt mir spontan ~/.xsession-errors ein. Wenn der artsd abgestürzt ist kannst du mal versuchen ihn von der Konsole aus zu starten (eben mit artsd), dann siehst du die Fehlermeldungen direkt.
Da steht was mit cannot find card '0'
In Zusammenhang mit kmix?
Nein. Ich habe jetzt mal versucht mittels chmod a+rw /dev/dsp0 rumzuspielen. Ergebnis: Kmix started jtzt ohne Probleme, und ich kann mit aplay einen sound abspielen, ABER ich bekomme regelmässig eine KDE-Absturzmeldung dass artsd abstürzt. Was ist das denn? Funktioniert der sound ohne artsd? Und warum started artsd ständig neu?
OK, das sieht alles nach einem Zugriffsproblem aus.
Ich habe versucht wie in Deiner ersten Fehlerlösung in der Datei /etc/... alles auf 0660 zu setzten, und neustarten, hat aber keine Änderung gebracht.
S.o.: "Bist du dir sicher, daß deine anderen Benutzer ..."
S.O. Danke für die Hilfe Gruss Karl
Am Samstag, 24. Dezember 2005 01:49 schrieb Karl:
Hallo Jan,
Am Freitag, 23. Dezember 2005 20:41 schrieb Jan Ritzerfeld:
Unter Karl oder root (halt bei den Benutzern mit funktionierendem artsd): jan@linux:~> artsshell status | grep "audio method:" audio method: alsa
Karl@linux:~> artsshell status | grep "audio method:" unix_connect: can't connect to server (unix:/tmp/ksocket-Karl/linux.site-261d-43ac9917) unable to connect to sound server
Spannend! :-( Die Ausgabe sieht so aus als liefe da ein artsd auf den du keinen Zugriff hast, aber der Sound funktioniert ja trotzdem. Was sagt denn "ps -F -p $(pidof artsd)"? Das ganze muß ich mal unter SL 10.0 ausprobieren, wenn ich da am WE wieder rankomme.
(...). Ich habe jetzt mal versucht mittels chmod a+rw /dev/dsp0 rumzuspielen. Ergebnis: Kmix started jtzt ohne Probleme, und ich kann mit aplay einen sound abspielen, ABER ich bekomme regelmässig eine KDE-Absturzmeldung dass artsd abstürzt. Was ist das denn? Funktioniert der sound ohne artsd? Und warum started artsd ständig neu?
Also bei der SL-10.0-Installation auf die ich Zugriff habe, ist gar kein artsd installiert, der Soundserver im KDE-Kontrollzentrum deaktiviert, die KDE-Systemklänge so eingestellt, daß sie den Soundserver benutzen und trotzdem funktioniert der Sound (auch unter KDE). Wenn ich den KDE-Soundserver versuche zu starten, kommt auch eine Fehlermeldung, daß der nicht gestartet werden konnte (wie auch, artsd ist ja nicht mal installiert). IIRC kommt bei "Sound testen" halt das Fenster mit dem Fortschrittsbalken, welcher irgendwann auch mal bis 100% geht und dann einfach wieder von vorne anfängt.
(...). Danke für die Hilfe
Naja, viel geholfen hat es ja nicht. :-/ Gruß Jan -- A wise man has something to say, a fool has to say something.
Karl wrote:
Hallo,
Audio funktioniert gut unter einem Benutzer und unter root, aber alle anderen Benutzer können nicht darauf zugreifen.
Was muss ich tun um den Zugriff für andere Benutzer freizugeben?
Seit einigen Suse-Versionen werden die Zugriffe auf Audio- und CD/DVD-Geräte mit resmgr vergeben. Hier sieht das für den Benutzer ser X-Session so aus: $ /sbin/resmgr list r--- /dev/console rw-- /dev/adsp rw-- /dev/audio rw-- /dev/dsp rw-- /dev/mixer rw-- /dev/snd/controlC0 rw-- /dev/snd/pcmC0D0c rw-- /dev/snd/pcmC0D0p rw-- /dev/snd/pcmC0D1c rw-- /dev/snd/pcmC0D2c rw-- /dev/snd/pcmC0D3c rw-- /dev/snd/pcmC0D4p rw-- /dev/snd/seq rw-- /dev/snd/timer rw-- /dev/input/event2 rw-- /dev/hdd rw-- /dev/hdc Du solltest dich also mal mit der Dokumentation zu resmgr/resmgrd auseinandersetzen, da kann man einiges einstellen. Z.B. habe ich schon mal hinbekommen, dass per ssh eingeloggte Benutzer CDs brennen dürfen, was sonst nur dem lokal angemeldeten Benutzer vorbehalten ist. -- Viele Grüße ------------------------------------------------------------------------ Michael
Hallo Michael, Am Montag, 19. Dezember 2005 15:25 schrieb Michael Behrens:
Hier sieht das für den Benutzer ser X-Session so aus:
$ /sbin/resmgr list r--- /dev/console rw-- /dev/adsp rw-- /dev/audio rw-- /dev/dsp rw-- /dev/mixer rw-- /dev/snd/controlC0 rw-- /dev/snd/pcmC0D0c rw-- /dev/snd/pcmC0D0p rw-- /dev/snd/pcmC0D1c rw-- /dev/snd/pcmC0D2c rw-- /dev/snd/pcmC0D3c rw-- /dev/snd/pcmC0D4p rw-- /dev/snd/seq rw-- /dev/snd/timer rw-- /dev/input/event2 rw-- /dev/hdd rw-- /dev/hdc
Du solltest dich also mal mit der Dokumentation zu resmgr/resmgrd auseinandersetzen, da kann man einiges einstellen. Z.B. habe ich schon mal hinbekommen, dass per ssh eingeloggte Benutzer CDs brennen dürfen, was sonst nur dem lokal angemeldeten Benutzer vorbehalten ist.
Hier sieht die Ausgabe von "resmgr list" bei beiden Usern gleich aus. und es wird auch der rw- Zugriff angezeigt. Gruss Karl
--
Viele Grüße
------------------------------------------------------------------------ Michael
Am Freitag, 23. Dezember 2005 19:07 schrieb Karl:
(...). Hier sieht die Ausgabe von "resmgr list" bei beiden Usern gleich aus. und es wird auch der rw- Zugriff angezeigt.
Oh. Da hat Michael durchaus recht, mittlerweile benutzen recht viele Programme den resmgr. Hier hat mich mal jemand zitiert, einen längeren Text über CD-Brennen als User und Sound für mehrere User: http://lists.suse.com/archive/suse-multimedia/2004-Nov/0244.html Jetzt müßte das nur noch bei dir funktionieren. "chmod g+rw /dev/snd/*" ist die Brechstangenmethode. Mal sehen, ob ich das elegant mit dem resmgr hinbekomme ... Bei mir sieht das jetzt so aus (nach der :0 -> :* Änderung in resmgr.conf): "resmgr list" zeigt rw-Zugriff für /dev/audio an, aplay sagt aber folgendes: tv@linux:~> aplay ALSA lib pcm_hw.c:1305:(_snd_pcm_hw_open) Invalid value for card ALSA lib pcm_dmix.c:819:(snd_pcm_dmix_open) unable to open slave aplay: main:544: audio open error: Kein passendes Gerät gefunden Wen wundert das auch. aplay will gar keinen Zugriff auf /dev/audio, sondern auf diverse Dateien in /dev/snd/ siehe "strace aplay" bei dem User, der die Rechte auch ohne resmgr schon hat. Das sind hier bei mir /dev/snd/controlC0, /dev/snd/pcmC0D0p und /dev/snd/timer. Darauf antwortet der resmgr natürlich mit "502 permission denied", weil die Dateien normalerweise nicht in /etc/resmgr.conf freigegeben werden. Das hole ich mal kurz nach: # # ALSA multimedia devices add /dev/snd/controlC0 desktop add /dev/snd/pcmC0D0p desktop add /dev/snd/timer desktop Schön! Jetzt sieht die Ausgabe genauso aus, wie bei dem Hauptnutzer: tv@linux:~> aplay ALSA lib timer_hw.c:269:(snd_timer_hw_open) extended read is not supported (SNDRV_TIMER_IOCTL_TREAD) Und wenn ich jetzt noch eine WAV-Datei angebe, wird die auch abgespielt. Danke Michael, jetzt habe ich ohne Brechstange Sound unter allen Nutzern parallel. :) Gruß Jan -- Only God can make a random selection. (Even though the computer randomly chose this message)
Hi Leute Bevor Ihr mit Zugriffsberechtigungen eventuell Euer System zu offen gestaltet empfielt sich zuerst immer die debug Methode. Entweder mit den debugger, den das Programm mitbringt, oder mit strace. Probiert mal strace -e open -f <programname> <option> und in 90% der Fälle, könnt Ihr auch das viele Rätzelraten sparen. Frohe Weinacht und viel Spass mit Eurem SuSE Jerome Reinert
participants (5)
-
Jan Ritzerfeld -
Jerome Reinert -
Karl -
Michael Behrens -
Michael Schueller