[pulseaudio-discuss] container support

Tue Dec 15 08:28:05 UTC 2020

I am more and more thinking that this is caused by the extra security /
sandboxing provided by systemd for user services (run as --user ).

So I think that pulseaudio version I am using is not taking the elevated
security provided by systemd into account.
*This is a big problem as it currently means that pulseaudio is broken
(useless).*

For more details see following forum post and also previous posts:
* https://forums.centos.org/viewtopic.php?f=54&t=76657&p=322366#p322366

Op di 15 dec. 2020 om 08:28 schreef Jan Van den Audenaerde <
jan.vandenaudenaerde at gmail.com>:

> Thanks for the response.
> I have checked all those things:
>
>    1.  my user is added to audio group
>    2. group ownershiup of folder in sound devices is indeed audio
>    3. no other pulseaudio daemon is running
>    4. no other process is accessing /dev/snd/*
>
> Also not that it is working from the command line, but it isn't working
> when launched as systemd user service.
>
> Can you share the pulseaudio / systemctl version you are using ?
>
> my complete configuration is documented :
> https://forums.centos.org/viewtopic.php?f=54&t=76657&p=322365#p322365
>
> many thanks
> Jan
>
> Op ma 14 dec. 2020 om 20:43 schreef GMAIL <temptempor at gmail.com>:
>
>> One important is that you should be in the group that has ReadWrite
>> access to the audio devices.
>>
>> On Arch, this would be the "audio" group, which my user is part of.
>>
>> Check the group ownership of the  sound devices and make sure the user
>> that wants to execute the PA server is part of those.
>>
>> Another thing there can only be one daemon owning the audio devices: if
>> you try to start a PA server while another is already exclusively accessing
>> them, your new PA daemon will fail to grab them.
>>
>> So there may indeed be further Systemd ever elusive restrictions in place
>> but make sure: Your user is in the right group, no other PA server is
>> running before executing the userspace service.
>> On 14/12/2020 15:57, Jan Van den Audenaerde wrote:
>>
>> Thanks for sharing.
>>
>> I tried this but when starting pulseaudio daemon as a systemd user
>> service it doesn't recognize the audio card.
>> I have reported the details of this issue under following forum topic:
>>
>>    - https://forums.centos.org/viewtopic.php?f=54&t=76657
>>
>> Note that it recognizes my audio card when launched from the command line
>> for the same user ,
>> so "systemctl --user" somehow restricts access to the device.
>>
>> kr
>> Jan
>>
>> Op zo 13 dec. 2020 om 19:27 schreef GMAIL <temptempor at gmail.com>:
>>
>>> I have this working:
>>>
>>> *Socket*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *# /usr/lib/systemd/user/pulseaudio.socket [Unit] Description=Sound
>>> System ConditionUser=!root [Socket] Priority=6 Backlog=5
>>> ListenStream=%t/pulse/native [Install] WantedBy=sockets.target*
>>>
>>> *Service*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *# /usr/lib/systemd/user/pulseaudio.service [Unit] Description=Sound
>>> Service # We require pulseaudio.socket to be active before starting the
>>> daemon, because # while it is possible to use the service without the
>>> socket, it is not clear # why it would be desirable. # # A user installing
>>> pulseaudio and doing `systemctl --user start pulseaudio` # will not get the
>>> socket started, which might be confusing and problematic if # the server is
>>> to be restarted later on, as the client autospawn feature # might kick in.
>>> Also, a start of the socket unit will fail, adding to the # confusion. # #
>>> After=pulseaudio.socket is not needed, as it is already implicit in the #
>>> socket-service relationship, see systemd.socket(5).
>>> Requires=pulseaudio.socket ConditionUser=!root [Service]
>>> ExecStart=/usr/bin/pulseaudio --daemonize=no --log-target=journal
>>> LockPersonality=yes MemoryDenyWriteExecute=yes NoNewPrivileges=yes
>>> Restart=on-failure RestrictNamespaces=yes SystemCallArchitectures=native
>>> SystemCallFilter=@system-service # Note that notify will only work if
>>> --daemonize=no Type=notify UMask=0077 [Install] Also=pulseaudio.socket
>>> WantedBy=default.target *
>>>
>>> Cheers
>>> On 13/12/2020 17:52, Jan Van den Audenaerde wrote:
>>>
>>> Hi,
>>>
>>> Thanks for the response.
>>>
>>> But how do I get the pulseaudio daemon running in userspace that is
>>> listening to unix socket /run/user/1000/pulse/native ?
>>> I don't want to start this daemon manually but as a systemd service.
>>>
>>> kr
>>> jan
>>>
>>>
>>> Op zo 13 dec. 2020 om 14:40 schreef GMAIL <temptempor at gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> This can be achieved fairly "simply" (as long as you know what to look
>>>> for).
>>>>
>>>> You need to pass the pulse socket into the container and tell pulse
>>>> clients inside the container its precise path.
>>>>
>>>> So on Docker CLI, for a typical Pulse daemon running in userspace, it
>>>> would be something like:
>>>> *-v /run/user/1000/pulse:/run/user/1000/pulse *
>>>>
>>>> Inside the container, once you've installed Pulseaudio, you need to
>>>> modify its client configuration:
>>>>
>>>> */etc/pulse/client.conf*
>>>>
>>>> *default-server = /run/user/1000/pulse/native*
>>>>
>>>> With this your Pulseaudio applications should be able to play sounds
>>>> through the host PulseAudio server (of course, you'd need to adapt the
>>>> runtime paths to your environment).
>>>>
>>>> Bear in mind, there seems to be some inconsistencies in the way various
>>>> Pulse utilities interface with the daemon. In this setup for example,
>>>> "pacmd" won't work, whilst "pactl" works fine once the client
>>>> configuration is fixed.
>>>>
>>>> You could test this in a manual way first and then automate things a
>>>> bit with a Dockerfile and what not.
>>>>
>>>> Best regards.
>>>> On 12/12/2020 16:19, Jan Van den Audenaerde wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have spend several days without success figuring out how I can use
>>>> pulseaudio in a container setup on an embedded device.
>>>>
>>>>
>>>>
>>>> *I am running CentOs 8 on a headless device (intel-nuc) which is also
>>>> running docker. I would like to run pulseaudio server on the host (CentOs
>>>> 8) and my docker containers should be able to use pulseaudio client to
>>>> communicate with the pulseaudio server via pulseaudio unix socket. Moreover
>>>> it should be possible that different docker containers can access the
>>>> microphone and speaker at the same time.*
>>>>
>>>>
>>>> The main problem I am facing I have reported in following forum post:
>>>>
>>>>
>>>>    - https://forums.centos.org/viewtopic.php?f=54&t=76643
>>>>
>>>>
>>>> Any help would be much appreciated.
>>>> I also think that pulseaudio has the good requirements for use in a
>>>> container setup if  I only can make it work.
>>>> Jan.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> pulseaudio-discuss mailing listpulseaudio-discuss at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>>>>
>>>> _______________________________________________
>>>> pulseaudio-discuss mailing list
>>>> pulseaudio-discuss at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>>>>
>>>
>>> _______________________________________________
>>> pulseaudio-discuss mailing listpulseaudio-discuss at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20201215/dab1763a/attachment-0001.htm>