Discussion:
How to change XDG_RUNTIME_DIR permissions
Add Reply
john terragon
2018-04-09 17:27:10 UTC
Reply
Permalink
Raw Message
Hi.
As far as I understand the XDG_RUNTIME_DIR (in debian it's /run/user/<user>) is created by the logind service.I want to make the socket of the pulseaudio server of one particular user available to all the others. In debian that socket is in $XDG_RUNTIME_DIR/pulse/. The problem is that $XDG_RUNTIME_DIR is created with 700 and even if I change (after it's been created) the permissions to 711, they are automatically changed back to 700 after few seconds (security feature?). Is there a  way to specify to logind (if that is indeed the service responsible) the permissions with which  $XDG_RUNTIME_DIR should be created?
Thanks
John.
Simon McVittie
2018-04-09 18:34:56 UTC
Reply
Permalink
Raw Message
Post by john terragon
created by the logind service.I want to make the socket of the pulseaudio
server of one particular user available to all the others.
This is basically PulseAudio system-wide mode:
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/SystemWide/
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/WhatIsWrongWithSystemWide/

... except worse, because instead of potentially being able to escalate
privileges to a dedicated system uid that runs the PulseAudio system
server, you can potentially escalate privileges to the account of
another user.

I would suggest using the system-wide mode instead: it's a bad idea
for all the reasons listed in the link above, but seems less bad than
reinventing it via a user's account.

smcv
Mantas Mikulėnas
2018-04-09 20:09:20 UTC
Reply
Permalink
Raw Message
Post by Simon McVittie
Post by john terragon
created by the logind service.I want to make the socket of the pulseaudio
server of one particular user available to all the others.
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/SystemWide/
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/WhatIsWrongWithSystemWide/
... except worse, because instead of potentially being able to escalate
privileges to a dedicated system uid that runs the PulseAudio system
server, you can potentially escalate privileges to the account of
another user.
I would suggest using the system-wide mode instead: it's a bad idea
for all the reasons listed in the link above, but seems less bad than
reinventing it via a user's account.
Except for the shared memory part, which I seem to remember has finally
been solved using memfd sealing?
Post by Simon McVittie
--
Mantas Mikulėnas <***@gmail.com>
Sent from my phone

Loading...