audio group
Hi you all, I am having trouble in using real time apps under gnome. When I add my user to the audio group in order to run RT apps (qjacktl) the login takes forever and I got this message: "There was an error starting the GNOME Settings Daemon. Some things, such as themes, sounds, or background settings may not work correctly. The last error message was: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. GNOME will still try to restart the Settings Daemon next time you log in." Running gnome-settings-daemon fro cli results in the same error. Removing the user from audio group fixes but on the other side it prevents me to run RT apps. It seems an alsa related issue but everything worked fine since I switched to gnome from kde. Any hints? regards raffaele Debian testing uname -a : Linux jimi 2.6.29-rt1-vanilla #1 SMP PREEMPT RT Fri Apr 3 20:37:26 CEST 2009 x86_64 GNU/Linux ii alsa-base 1.0.19.dfsg-3 ALSA driver configuration files ii alsa-oss1.0.17-1ALSA wrapper for OSS applications ii alsa-tools 1.0.19-1Console based ALSA utilities for specific hardware ii alsa-tools-gui 1.0.19-1GUI based ALSA utilities for specific hardware ii alsa-utils 1.0.19-2ALSA utilities ii gstreamer0.10-alsa 0.10.22-4 GStreamer plugin for ALSA ii gstreamer0.10-ffmpeg0.10.7-1 FFmpeg plugin for GStreamer ii gstreamer0.10-gnomevfs 0.10.22-4 GStreamer plugin for GnomeVFS ii gstreamer0.10-plugins-bad 0.10.10.3-1 GStreamer plugins from the "bad" set ii gstreamer0.10-plugins-base 0.10.22-4 GStreamer plugins from the "base" set ii gstreamer0.10-plugins-good 0.10.14-2 GStreamer plugins from the "good" set ii gstreamer0.10-plugins-ugly 0.10.11-1 GStreamer plugins from the "ugly" set ii gstreamer0.10-tools 0.10.22-2 Tools for use with GStreamer ii gstreamer0.10-x 0.10.22-4 GStreamer plugins for X11 and Pango
Re: audio group
Le lundi 13 avril 2009 à 09:57 +0200, Raffaele a écrit : > Running gnome-settings-daemon fro cli results in the same error. > Removing the user from audio group fixes but on the other side it > prevents me to run RT apps. This looks like a broken GStreamer plugin that makes the daemon crash upon startup. There has been a problem with the ladpsa plugin recently, so this might be the same issue. -- .''`. Debian 5.0 "Lenny" has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: audio group
2009/4/13 Josselin Mouette > Le lundi 13 avril 2009 à 09:57 +0200, Raffaele a écrit : > > Running gnome-settings-daemon fro cli results in the same error. > > Removing the user from audio group fixes but on the other side it > > prevents me to run RT apps. > > This looks like a broken GStreamer plugin that makes the daemon crash > upon startup. There has been a problem with the ladpsa plugin recently, > so this might be the same issue. Very annoying, swicth back to KDE. regards r
RFC: Realtime system (audio) group
Hi! [background story: pro-audio applications run with POSIX realtime priorities to meet low-latency deadlines. We ship /etc/security/limits.d/audio.conf in the jackd packages to grant rt privileges to the audio group] As outlined in #656910, "being in the audio group" and "having realtime priorities" aren't separated at the moment. To make these two independent, we'd need to use a different (new?) group for realtime priorities. We can call this group "rtaudio", but maybe somebody prefers a more generic name, e.g., "realtime". Maybe there is already such a group. WDYT? Cheers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1fda28.9020...@drcomp.erfurt.thur.de
Re: RFC: Realtime system (audio) group
On 25/01/12 10:32, Adrian Knoth wrote: As outlined in #656910, "being in the audio group" and "having realtime priorities" aren't separated at the moment. To make these two independent, we'd need to use a different (new?) group for realtime priorities. rtkit (packaged in Debian) seems a safer way to do this than group-based privileges + setuid root. It doesn't just hand out realtime priorities, it also has a watchdog thread with a higher priority than the rt application itself, so it can carry out an emergency de-prioritization on the rt application to get control back to your shell/UI if the system becomes unresponsive. If you have PolicyKit, rtkit defaults to letting you have rt priorities if and only if you are logged in locally (gdm, kdm, getty etc., but not ssh); as with all PK services, the policy is configurable (so a local admin could give this privilege to the audio or users group, or a new group). I'm not sure what its fallback policy is if you don't have PK. The Debian packages for pulseaudio used to create a pulse-rt group which granted access to realtime priority for the user's instance of the pulseaudio daemon (basically what you're proposing, but Pulse-specific), but since 0.9.16 it's just recommended rtkit instead. Having to add users to an ever-increasing number of groups so they can run applications as intended seems like an anti-pattern, if there's a sensible default (e.g. involving "only if logged-in locally") with configuration that can override it; this is why PK exists. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1fe9aa.6060...@debian.org
Re: RFC: Realtime system (audio) group
On Wed, Jan 25, 2012 at 11:32:08AM +0100, Adrian Knoth wrote: > [background story: pro-audio applications run with POSIX realtime > priorities to meet low-latency deadlines. We ship > /etc/security/limits.d/audio.conf in the jackd packages to grant rt > privileges to the audio group] Why does jackd not grant _itself_ RT priority? It can grant itself CAP_SYS_NICE, which allows arbitrary mangling of priorities. It could still limit the usage for users with the audio group and just drop the capability of the user is not in this group. Bastian -- No one can guarantee the actions of another. -- Spock, "Day of the Dove", stardate unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120125114347.ga20...@wavehammer.waldi.eu.org
Re: RFC: Realtime system (audio) group
On Wed, Jan 25, 2012 at 11:38:18AM +, Simon McVittie wrote: > rtkit (packaged in Debian) seems a safer way to do this than > group-based privileges + setuid root. Why does it use setuid and not CAP_SYS_NICE? Bastian -- We Klingons believe as you do -- the sick should die. Only the strong should live. -- Kras, "Friday's Child", stardate 3497.2 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120125114442.gb20...@wavehammer.waldi.eu.org
Re: RFC: Realtime system (audio) group
On 01/25/2012 12:44 PM, Bastian Blank wrote: On Wed, Jan 25, 2012 at 11:38:18AM +, Simon McVittie wrote: rtkit (packaged in Debian) seems a safer way to do this than group-based privileges + setuid root. Why does it use setuid It doesn't use setuid root. Simon has wrongly assumed this. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1fec99.4060...@drcomp.erfurt.thur.de
Re: RFC: Realtime system (audio) group
On 01/25/2012 12:43 PM, Bastian Blank wrote: [background story: pro-audio applications run with POSIX realtime priorities to meet low-latency deadlines. We ship /etc/security/limits.d/audio.conf in the jackd packages to grant rt privileges to the audio group] Why does jackd not grant _itself_ RT priority? It can grant itself CAP_SYS_NICE, which allows arbitrary mangling of priorities. # setcap cap_sys_nice,cap_ipc_lock+eip /usr/bin/jackd Works, but is hardly an improvement. It's either a stability risk (if not limited) or: It could still limit the usage for users with the audio group and just drop the capability of the user is not in this group. Which would still require the user to be part of a special group. The audio group can't be used for this, as it would again combine "access to sound card" and "have realtime permissions" as described in #656910. So we're back at how to name this group. ;) Cheers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1ff2ea.8090...@drcomp.erfurt.thur.de
Re: RFC: Realtime system (audio) group
On 01/25/2012 12:38 PM, Simon McVittie wrote: As outlined in #656910, "being in the audio group" and "having realtime priorities" aren't separated at the moment. To make these two independent, we'd need to use a different (new?) group for realtime priorities. rtkit (packaged in Debian) seems a safer way to do this than group-based privileges + setuid root. As already pointed out, there is no setuid binary. it also has a watchdog thread with a higher priority than the rt application itself, so it can carry out an emergency de-prioritization on the rt application to get control back to your shell/UI if the system becomes unresponsive. RT CPU bandwidth is limited to 95% these days. No need for a watchdog anymore. If you have PolicyKit, rtkit defaults to letting you have rt priorities if and only if you are logged in locally (gdm, kdm, getty etc., but not Is there something like "If you're logged in locally, I'll grant you RT prios"? that does not require the application to use dbus? So to say, "@local" PAM magic or inherited from gdm/kdm/getty? Can policykit do this? This would be a good compromise between "make it work for the local user without messing with groups", but still leaving enough freedom for the experienced if ssh is required. Note that this would change the default ulimits if logged in locally. We'd end up with every local user having RT priorities and more or less unlimited memory locking. AFAIK, it's what OSX does, but it might require some discussion if it's desired to have the same in Debian. Cheers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1ff63a.1000...@drcomp.erfurt.thur.de
Re: RFC: Realtime system (audio) group
Le mercredi 25 janvier 2012 à 13:31 +0100, Adrian Knoth a écrit : > > If you have PolicyKit, rtkit defaults to letting you have rt priorities > > if and only if you are logged in locally (gdm, kdm, getty etc., but not > > Is there something like > > "If you're logged in locally, I'll grant you RT prios"? > > that does not require the application to use dbus? So to say, "@local" > PAM magic or inherited from gdm/kdm/getty? Currently two things are supported by ConsoleKit/PolicyKit: D-Bus interfaces, and device permissions (udev sets dynamic ACLs on some devices when you are on the console). If you need things like Unix sockets, currently there is no code to support them (but there is no technical limitation). -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1327584742.17752.589.camel@pi0307572
What is the policy on audio group? and, proposal of a new group for the jack audio server
Hi. I'm the project leader for Ubuntu Studio and a prospective Debian developer. My work tends to focus mostly on multimedia production related topics, and specifically audio production. My main objective right now is just to try making audio production easier for regular users, and this is still a big problem on most Linux based distributions. Some of this relates to the usage of audio group. First off, is there a clear policy on the use of audio group in Debian? I did find some explanations on the usage of it on this page, under 'Should users be in the "audio" group?' http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PerfectSetup/, and from what I can determine, Debian would then fall under category 2 as explained in the text. Is that what Debian wants? I know that many distros do not use the audio group as default for users. I suspect for reasons as explained on this page https://wiki.ubuntu.com/Audio/TheAudioGroup. Audio group is also used by the jack audio server for granting realtime scheduling privilege to users. Packages jackd1 and jackd2 install a pam setting file which grants "rtprio" and "memlock" privilege to audio group. Package libffado2 installs a udev rules file granting audio group privilege to a set of firewire audio cards (which are primarily used with jack). This is quite a nice setup, since users are already in audio group and need only install jack in order to get the benefit of realtime scheduling. - This is however not a universal, standardized approach, since not all distros want the users to be in audio group. Usage of pam for granting realtime privilege *is* a standard approach though. It is what all audio production tuned distros do, and it is what people manually do on distros that doesn't provide it OOTB. The main difference is the group name used (in Ubuntu Studio, we also use the audio group - mainly because the Debian packages we import expect it). So, I would propose to use a new group, specifically for jack (and ffado). Why? If Debian adds such a group, and the Debian packages for jack and ffado make use of it, making ease of installation of Debian derived distros will greatly simplify and it would be more likely those distros would be willing to also add that group as a default group for users. At least, there would be no conflict, as is the case with audio group. And by that point, things actually do greatly simplify for regular users. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1414358356.2467889.183498341.324fe...@webmail.messagingengine.com
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On Oct 26, Kaj Ailomaa wrote: > I did find some explanations on the usage of it on this page, under > 'Should users be in the "audio" group?' > http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PerfectSetup/, > and from what I can determine, Debian would then fall under category 2 > as explained in the text. Is that what Debian wants? Yes. > Package libffado2 installs a udev rules file granting audio group > privilege to a set of firewire audio cards (which are primarily used > with jack). This is quite a nice setup, since users are already in audio > group and need only install jack in order to get the benefit of realtime > scheduling. Debian users should not be in the audio group: if the devices are not already covered by the rules in /lib/udev/rules.d/71-seat.rules then they should be tagged with TAG+="seat" so that users on the local consoles will be able to access them.. > So, I would propose to use a new group, specifically for jack (and I see no obvious downsides. -- ciao, Marco signature.asc Description: Digital signature
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On Sun, Oct 26, 2014, at 11:36 PM, Marco d'Itri wrote:
> On Oct 26, Kaj Ailomaa wrote:
>
> > I did find some explanations on the usage of it on this page, under
> > 'Should users be in the "audio" group?'
> > http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PerfectSetup/,
> > and from what I can determine, Debian would then fall under category 2
> > as explained in the text. Is that what Debian wants?
> Yes.
>
> > Package libffado2 installs a udev rules file granting audio group
> > privilege to a set of firewire audio cards (which are primarily used
> > with jack). This is quite a nice setup, since users are already in audio
> > group and need only install jack in order to get the benefit of realtime
> > scheduling.
> Debian users should not be in the audio group: if the devices are not
> already covered by the rules in /lib/udev/rules.d/71-seat.rules then
> they should be tagged with TAG+="seat" so that users on the local
> consoles will be able to access them..
Ok, so you are for removing audio group from user default groups?
I'm not very familiar with udev rules, but the rules for ffado point to
audio group.
The beginning of 60-ffado.rules (in package libffado2):
SUBSYSTEM!="firewire", GOTO="ffado_end"
# TC GROUP A/S
ATTR{vendor}=="0x000166", GROUP="audio", ENV{ID_FFADO}="1"
# Mark of the Unicorn, Inc. (aka MOTU)
ATTR{vendor}=="0x0001f2", GROUP="audio", ENV{ID_FFADO}="1"
Would these be able to be tagged with "seat" as you mention?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1414374505.2513381.183566945.64743...@webmail.messagingengine.com
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On Oct 27, Kaj Ailomaa wrote: > Ok, so you are for removing audio group from user default groups? Eventually, yes. > Would these be able to be tagged with "seat" as you mention? Actually the correct tag is uaccess, and /lib/udev/rules.d/70-uaccess.rules will already do it for you for all ID_FFADO devices. -- ciao, Marco signature.asc Description: Digital signature
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
Am Montag, den 27.10.2014, 02:58 +0100 schrieb Marco d'Itri: > On Oct 27, Kaj Ailomaa wrote: > > > Ok, so you are for removing audio group from user default groups? > Eventually, yes. Did you mean "maybe" or "for sure, someone" Just to avoid an (common) non-native* error: eventually != maybe -- tobi * I'm also non-native speaker -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1414392184.28211.1.ca...@frost.de
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On Oct 27, Tobias Frost wrote: > > > Ok, so you are for removing audio group from user default groups? > > Eventually, yes. > Did you mean "maybe" or "for sure, someone" No. -- ciao, Marco signature.asc Description: Digital signature
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
Hi, Marco d'Itri: > On Oct 27, Tobias Frost wrote: > > > > > Ok, so you are for removing audio group from user default groups? > > > Eventually, yes. > > Did you mean "maybe" or "for sure, someone" s/someone/sometime/ > No. > Then what *did* you mean? -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141027111318.ga11...@smurf.noris.de
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
Hi, > Marco d'Itri: >> On Oct 27, Tobias Frost wrote: >> >>>>> Ok, so you are for removing audio group from user default groups? >>>> Eventually, yes. >>> Did you mean "maybe" or "for sure, someone" > > s/someone/sometime/ > >> No. >> > Then what *did* you mean? Well, probably the correct English meaning of "eventually", which is, "at some (unspecified) point in the future". :) Kind regards Ralf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5451695b.2090...@ralfj.de
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
Am Mittwoch, den 29.10.2014, 23:25 +0100 schrieb Ralf Jung: > Hi, > > > Marco d'Itri: > >> On Oct 27, Tobias Frost wrote: > >> > >>>>> Ok, so you are for removing audio group from user default groups? > >>>> Eventually, yes. > >>> Did you mean "maybe" or "for sure, someone" > > > > s/someone/sometime/ > > > >> No. > >> > > Then what *did* you mean? > > Well, probably the correct English meaning of "eventually", which is, > "at some (unspecified) point in the future". :) ... but its already determined that it *will* happen; Probably Ralf meant that, but I think it needs to be said more explicit: This is just such a common false-friend-error in many languages [1]; and the false-friends-meaning is "possible", maybe "maybe" . I think the word "eventually" should be avoided. Its just too likely you get misunderstood. [1] http://www.macmillandictionaries.com/MED-Magazine/May2003/07-important-actual-eventual.htm#3 > Kind regards > Ralf > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1414701606.25653.1.ca...@frost.de
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On Mon, Oct 27, 2014, at 02:58 AM, Marco d'Itri wrote: > On Oct 27, Kaj Ailomaa wrote: > > > Ok, so you are for removing audio group from user default groups? > Eventually, yes. > So, who determined that audio group will not be used as a default user group in Debian, and when you say eventually, do you mean Debian 9? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415541225.645217.188812509.7715a...@webmail.messagingengine.com
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On 09/11/14 13:53, Kaj Ailomaa wrote: > So, who determined that audio group will not be used as a default user > group in Debian As far as I know, nobody yet. Marco was expressing what he thinks should happen in future, not what has happened already. I agree with his opinion on this. > and when you say eventually, do you mean Debian 9? I think that would be a good timescale, yes. Members of the audio group can play and record[1] audio via remote logins, even when not physically present at the hardware. To me, that doesn't seem consistent with a "least astonishment" policy for users of a shared machine to have privacy from each other: if I have a private conversation "in real life" while using a shared computer, and Bob has an account on that computer but is not present or logged-in locally, it doesn't seem desirable for Bob to be able to record my conversation. On systems with infrastructure to adjust device ACLs during login, the audio group is unnecessary for normal operation: when you log in locally, the infrastructure can set the ACL to allow you to access the audio device nodes, and when you log out, it can remove that ACL entry. (One of the things systemd-logind does is that it is one implementation of that infrastructure; I think ConsoleKit was another.) As far as I'm aware, if a sysadmin wants to designate privileged users who can play and record audio without being logged-in locally, they can still add those users to the audio group. S [1] assuming a microphone is present; this has not traditionally been the case on desktop- or tower-style PCs, but many laptops do have a built-in microphone, and not all have a mute button or LED for it -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545f7b52.2090...@debian.org
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On Sun, Nov 09, 2014 at 02:33:54PM +, Simon McVittie wrote: > On 09/11/14 13:53, Kaj Ailomaa wrote: > > So, who determined that audio group will not be used as a default user > > group in Debian > > As far as I know, nobody yet. Marco was expressing what he thinks should > happen in future, not what has happened already. I agree with his > opinion on this. > > > and when you say eventually, do you mean Debian 9? > > I think that would be a good timescale, yes. > > Members of the audio group can play and record[1] audio via remote > logins, even when not physically present at the hardware. To me, that > doesn't seem consistent with a "least astonishment" policy for users of > a shared machine to have privacy from each other: if I have a private > conversation "in real life" while using a shared computer, and Bob has > an account on that computer but is not present or logged-in locally, it > doesn't seem desirable for Bob to be able to record my conversation. On the other hand, it would break typical uses of using sound remotely. These days, shared computers are almost unheard of save for some school settings -- while loads of people have some raspi mediacenter or press some buttons on their phone to control sound coming from the big computer. Removing the primary user from the audio group would mean you need to do unobvious (for a non-sysadmin) configuration changes for something most people take for granted. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109151954.ga17...@angband.pl
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
Hi, > On the other hand, it would break typical uses of using sound remotely. > These days, shared computers are almost unheard of save for some school > settings -- while loads of people have some raspi mediacenter or press > some buttons on their phone to control sound coming from the big computer. This usually happens via UPnP or similar, though - the actual audio is ultimately done by a local user. So the audio group is unrelated to this usecase. Kind regards Ralf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545f8ff1.20...@ralfj.de
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
* Ralf Jung [141109 17:02]: > Hi, > > > On the other hand, it would break typical uses of using sound remotely. > > These days, shared computers are almost unheard of save for some school > > settings -- while loads of people have some raspi mediacenter or press > > some buttons on their phone to control sound coming from the big computer. > > This usually happens via UPnP or similar, though - the actual audio is > ultimately done by a local user. So the audio group is unrelated to this > usecase. It very much is, because those users are usually daemon users that are not logged in through a session manager, and thereby don't get access granted by PolicyKit (or equiv). -- ,''`. Christian Hofstaedtler : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- pgpNUvb5czB6Z.pgp Description: PGP signature
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On 09/11/14 23:34, Christian Hofstaedtler wrote: >>> On the other hand, it would break typical uses of using sound remotely. >> >> This usually happens via UPnP or similar, though - the actual audio is >> ultimately done by a local user. So the audio group is unrelated to this >> usecase. > > It very much is, because those users are usually daemon users that > are not logged in through a session manager, and thereby don't get > access granted by PolicyKit (or equiv). Fine, put those daemon users in the audio group - in their packages' postinst scripts, if necessary. I'm not saying that the audio group should be abolished, only that "normal user" accounts (as created by d-i, gnome-control-center, etc.) should ideally not be members of it. FYI, PolicyKit is not actually relevant here: the actual access control for (most uses of) the audio group is done by the kernel, when an application running as the target user (often something like PulseAudio or JACK, rather than the actual user-facing application) tries to open the audio device nodes. systemd-logind implements "locally-logged-in users may use audio devices" by setting ACLs on the device nodes for those users: % getfacl /dev/snd/pcmC0D0p getfacl: Removing leading '/' from absolute path names # file: dev/snd/pcmC0D0p # owner: root # group: audio user::rw- user:smcv:rw- group::rw- mask::rw- other::--- (In this case, smcv is the only locally-logged-in user.) S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545ffecd.4050...@debian.org
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
* Simon McVittie [141110 00:55]: > On 09/11/14 23:34, Christian Hofstaedtler wrote: > >>> On the other hand, it would break typical uses of using sound remotely. > >> > >> This usually happens via UPnP or similar, though - the actual audio is > >> ultimately done by a local user. So the audio group is unrelated to this > >> usecase. > > > > It very much is, because those users are usually daemon users that > > are not logged in through a session manager, and thereby don't get > > access granted by PolicyKit (or equiv). > > Fine, put those daemon users in the audio group - in their packages' > postinst scripts, if necessary. I'm not saying that the audio group > should be abolished, only that "normal user" accounts (as created by > d-i, gnome-control-center, etc.) should ideally not be members of it. I fully agree; it's just that the audio group can't just vanish. > FYI, PolicyKit is not actually relevant here: the actual access control > for (most uses of) the audio group is done by the kernel, when an > application running as the target user (often something like PulseAudio > or JACK, rather than the actual user-facing application) tries to open > the audio device nodes. systemd-logind implements "locally-logged-in > users may use audio devices" by setting ACLs on the device nodes for > those users: > [..] I vaguely remember PolicyKit being involved in the daemon situation, when mpd tries to talk to a pulseaudio server which magically gets spawned ... I'll probably just have to figure out the details again when any of the moving bits change. Cheers, -- ,''`. Christian Hofstaedtler : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- pgpOr3V1e568B.pgp Description: PGP signature
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On 10/11/14 02:59, Christian Hofstaedtler wrote: > I vaguely remember PolicyKit being involved in the daemon situation, > when mpd tries to talk to a pulseaudio server which magically gets > spawned PolicyKit is typically (only?) used when a less-privileged process, typically a user interface, communicates with a more-privileged service. It's possible that something PK-related is going on, but I can't immediately see any reason why either mpd or PulseAudio would want to interact with it: both normally run with an ordinary user's privileges. The typical scenario is: * I tell NetworkManager to connect to a wireless network (or tell some other privileged service to do some other action) * NetworkManager (or other privileged service) asks PolicyKit "is it OK to let smcv do this?" * PolicyKit consults its sysadmin-, distro- or upstream-supplied policies, checks the facts relevant to those policies (I am in some groups, I am actively logged-in locally), optionally asks me for my password to confirm that I am actually present, and replies "yes" or "no" Regards, S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54609cb6.6060...@debian.org
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
I would assume the way to go forward would be to report a bug on this? I have a faint memory of there already being one, but I couldn't find it anywhere. Also, my last bug report got closed - and I'm not even sure what to report it against (base?). Perhaps someone else would be more competent at writing one, or could provide some tips for me on how to do it? Seems to me there's somewhat an agreement on that audio group should stay, but "regular" user accounts should not be in it by default. This is the way many other distros do. Also, the main reason why I bring this up is on account of the jack audio server. The jackd1/jackd2 package assumes the user is a member of audio group, which is key in getting realtime privilege for the user who installs jack. Jack installs a file in /etc/security/limits.d, granting rtprio and memlock to audio group. Whenever I bring this up, someone tells me that we should use something else, like rt-kit, or using cgroups (which I have been experimenting with lately, but was unable to get to work for some reason - I can provide more info if someone is interested). Though this is a bit premature, until we can provide another solution, and if the user is made to not be default member of audio group, I would like it if there was a new group specifically for jack. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415642631.1344497.189280829.4053f...@webmail.messagingengine.com
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On Mon, 10 Nov 2014 11:08:38 +, Simon McVittie wrote: > On 10/11/14 02:59, Christian Hofstaedtler wrote: >> I vaguely remember PolicyKit being involved in the daemon situation, >> when mpd tries to talk to a pulseaudio server which magically gets >> spawned > > PolicyKit is typically (only?) used when a less-privileged process, > typically a user interface, communicates with a more-privileged service. > It's possible that something PK-related is going on, but I can't > immediately see any reason why either mpd or PulseAudio would want to > interact with it: both normally run with an ordinary user's privileges. > > The typical scenario is: > > * I tell NetworkManager to connect to a wireless network > (or tell some other privileged service to do some other action) > > * NetworkManager (or other privileged service) asks PolicyKit "is it OK > to let smcv do this?" > > * PolicyKit consults its sysadmin-, distro- or upstream-supplied > policies, checks the facts relevant to those policies (I am in > some groups, I am actively logged-in locally), optionally asks me > for my password to confirm that I am actually present, and replies > "yes" or "no" I'm not sure if it is PolicyKit or a related service (old documentation suggests it was ConsoleKit, nowadays it should be logind?), but /dev/snd/ * get ACLs added for the currently logged in users: % getfacl /dev/snd/controlC0 getfacl: Removing leading '/' from absolute path names # file: dev/snd/controlC0 # owner: root # group: audio user::rw- user:felipe:rw- group::rw- mask::rw- other::--- Thus any user (not on the audio group) process will not have access to the audio device until that user is on a physical terminal. AFAICT, pulseaudio does not talk directly to polkitd. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3t1gp$77d$1...@ger.gmane.org
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On 11/11/14 13:04, Felipe Sateler wrote: > I'm not sure if it is PolicyKit or a related service (old documentation > suggests it was ConsoleKit, nowadays it should be logind?), but /dev/snd/ > * get ACLs added for the currently logged in users Yes, that's exactly what I said a couple of mails ago :-) It is indeed systemd-logind that does this now. It's a 2-stage process: udev rules like /lib/udev/rules.d/50-udev-default.rules mark devices that should be user-accessible with the "uaccess" tag during device discovery (and sysadmin-written rules can presumably override the defaults to remove that tag if necessary). Later, systemd-logind looks for any devices with that tag and puts appropriate ACLs on them. Older versions of udev and ConsoleKit cooperated to do something similar with a "udev-acl" tag. PolicyKit is not involved here. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54621ffd.4090...@debian.org
Re: What is the policy on audio group? and, proposal of a new group for the jack audio server
On Tue, 11 Nov 2014 14:41:01 +, Simon McVittie wrote: > On 11/11/14 13:04, Felipe Sateler wrote: >> I'm not sure if it is PolicyKit or a related service (old documentation >> suggests it was ConsoleKit, nowadays it should be logind?), but >> /dev/snd/ >> * get ACLs added for the currently logged in users > > Yes, that's exactly what I said a couple of mails ago :-) Oops :) > > It is indeed systemd-logind that does this now. It's a 2-stage process: > udev rules like /lib/udev/rules.d/50-udev-default.rules mark devices > that should be user-accessible with the "uaccess" tag during device > discovery (and sysadmin-written rules can presumably override the > defaults to remove that tag if necessary). Later, systemd-logind looks > for any devices with that tag and puts appropriate ACLs on them. > > Older versions of udev and ConsoleKit cooperated to do something similar > with a "udev-acl" tag. > > PolicyKit is not involved here. Thanks for the clarification. I'll just that the relevant file is /lib/udev/rules.d/70-uaccess.rules for systemd systems, and /l/u/r/70-udev-acl.rules for consolekit systems. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3t858$8no$1...@ger.gmane.org
