On Fri, May 22, 2020 at 06:57:00AM +0200, Sebastien Marie wrote:
> On Thu, May 21, 2020 at 11:07:39PM +0100, Ricardo Mestre wrote:
> > Hi,
> >
> > After the handle sioctl_hdl `hdl' is opened (which in itself requires rw fs
> > access and opening an unix socket) then all operations happen over that
> > handle
> > so the program may be restricted to only "stdio".
> >
> > All options were tested successfully, including the examples from the
> > manpage
> > plus tweaking the audio from an app ($MYBROWSER).
>
> Did you only perform runtime checking ? or also auditing the code source ?
>
> Because depending your hardware and the way sndiod is configured, it isn't
> necessary the same code path used.
>
> Just one example: with device "snd/0", the sioctl_open() will use
> _sioctl_aucat_open() for handler initialisation, whereas with "rsnd/0", it is
> _sioctl_sun_open().
>
> As all functions called after sioctl_open() are using the handler, you might
> have tested only a part of the code path.
>
> I didn't look deeper. So it might fine, but it could also break some
> configurations.
I looked a bit deeper.
commit()
sioctl_setval()
[with "rsnd/0"]
sioctl_sun_setctl()
setvol()
ioctl(hdl->fd, AUDIO_MIXER_WRITE, &ctrl)
calling ioctl(AUDIO_MIXER_WRITE) should required "audio".
whereas when using default "snd/0" device, it is calling sioctl_aucat_setctl()
and it will write(2) a message to sndiod(8) (and "stdio" is enough).
I agree that "rsnd/0" isn't the standard case (it requires root to read/write to
/dev), but it means you will broke sndioctl(1) in such cases.
Thanks.
--
Sebastien Marie
