Haai,
"Alexandre Ratchov" <a...@caoua.org> wrote:
> On Sat, Apr 18, 2020 at 03:53:19PM -0700, Renato Aguiar wrote:
>> Hi,
>>
>> After updating to latest snapshot, mixerctl stopped working with non-root
>> user:
>>
>> $ mixerctl
>> mixerctl: /dev/audioctl0: Permission denied
>> $ ls -l /dev/audioctl0
>> crw-rw---- 1 root _sndiop 42, 192 Apr 18 14:29 /dev/audioctl0
>> $
>>
>[snip]
>
> Access to audio and MIDI related device nodes is now disabled for
> security reasons. We don't want programs we run, possibly processing
> untrusted input, to be allowed to directly access low level drivers
> and attempt to exploit kernel bugs.
Mefinds this issue to be analogous to the X(7) permission one (the one
that led to -s for Xorg(1)).
> Now programs connect to sndiod which does the hardware access for
> them, this has other advantages as well:
> - programs control the volume of the right device on systems with
> multiple audio devices (ex. usb head sets)
> - there's always a volume control, even if the hardware lacks one, as
> may usb devices.
> - unified view of hardware and software controls, network
> transparency, etc
That may all be, but like xenodm(1), memight find (future tense, as me's
not running -current or snapshots) the above proposed solution
inadequate for me needs. Right now, for both X(7) and the parts of audio
not covered for me by sndio(7), me's somewhat working around the
security issues by having the relevant device nodes only accessible (and
Xorg(1) only executable) by me as a luser (via groups 'x11' and 'audio',
respectively).
Me's not propagating the above as a solution; yet, as a workaround, me's
found it to be a life-saver.
Take care,
--zeurkous.
--
Friggin' Machines!
