![](https://seccdn.libravatar.org/avatar/a4139df10120ce151e457fd1faff018d.jpg?s=120&d=mm&r=g)
On 9/11/20 5:16 PM, tomas.kuchta.lists@gmail.com wrote:
On Fri, 2020-09-11 at 12:52 +0930, Simon Lees wrote:
On 9/11/20 10:05 AM, tomas.kuchta.lists@gmail.com wrote:
If someone could explain this in a few sentences - I would really appreciate it.
https://wiki.ubuntu.com/Audio/TheAudioGroup except instead of using consolekit it now uses parts of the systemd/logind stack. In short a user who is logged in graphically will gain access to audio / keyboard / mouse / display devices. A user logged in remotely should generally not have access as a security feature.
Thank you Simon - I am starting to connect the dots - this is real deep rabbit hole though.
Carlos mentioned seats - I thought that it is just bad translation for user account - I am slowly starting to remember the old mainframes and Vax's and their system topology.
I will dig little deeper - though - I am not sure that this whole thing is meant to be dynamically configurable by user rather than rewriting sddm or systemd or .... to implement assigning seat to vnc session when there is no active local session with the seat need + some sort of seat switching or moving HW around the seats with priorities .....
There seems to be handful of random people trying to figure this out every decade. There is a lot of info about introspection API - not so much how to control it beside header files and programming interface description to D.Bus. Maybe, creating a seat for VNC session and assigning a sound card to it is as simple as adding some magic d.Bus calls to VNC xstartup.
My early guess is that I will not be able to come up with anything better than the audio group membership with all its possible side effects - within a day or two before I giving up.
If its a signal user machine or you trust all the users that you want to give access to the audio group then there are no downsides to adding the user to the audio group. The defaults these days is users shouldn't have to because they will login normally. The reason it is setup like this is for places like universities where multiple users may share the same computer in a lab but you only want the one that is actually sitting at the desk in front of the PC to have access (This is the idea of the user with the seat). Atleast when I was at uni it was possible to ssh into a imac that someone else was sitting at and play music on there computer, they couldn't do anything to stop the music this is not ideal so the default configuration prevents it, in your case you want it for good reason hence needing to do something non standard. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B