[pulseaudio-discuss] PA_REALTIME_GROUP not honored if over 1000
jimc at math.ucla.edu
Fri Jul 27 21:53:34 PDT 2007
Versions: PulseAudio 0.9.6 on SuSE 10.2, kernel 220.127.116.11
File: /pulseaudio-0.9.6/src/daemon/main.c line 349
When an ordinary user executes /usr/local/bin/pulseaudio (mode 4755)
it prints this on stderr:
W: main.c: WARNING: called SUID root, but not in group 'pulse-rt'.
W: core-util.c: setpriority(): Permission denied
W: core-util.c: sched_setscheduler(): Operation not permitted
/usr/local/etc/pulse/daemon.conf contains, among others,
"high-priority = 1" (which could not be honored after privileges were
dropped). /etc/group contains this: pulse-rt:!:1001:pulse,root,jimc
Workaround: When I change the GID to 601, the messages go away.
My first complaint is that main.c line 349 explicitly tests if the GID of
PA_REALTIME_GROUP (pulse-rt) is over a hardwired limit of 1000. In SuSE
the conventional limit of system groups is 500; it is not reasonable for
every distro to follow the limit used by PulseAudio. Conversely, I made my
pulse-rt GID outside the system range since I've been burned in the past
when non-distro packages' GIDs overlapped values the distro wanted to use.
I don't see any reason, beyond locally decided administrative neatness,
for particular ranges of GIDs to have different semantics from other
ranges. The request is to lose the test "|| gid >= 1000" in line 349.
Second, I (and other forum posters) had a lot of trouble to identify
*which* user needs to be in group pulse-rt, which is why I put all three
relevant users there. Having looked at the source I can now see that the
executing user is the one (or maybe <pulse> for a systemwide daemon?)
I'm not sure where in the docs this info belongs, but it belongs somewhere:
"use the source, Luke" is fine for us gurus, but if we want Linux to
increase market share we need to provide some warm fuzziness in the form of
Third, I wonder whether we really need to allow some users to use realtime
priority with PulseAudio and lock out other users. The whole issue could
be bypassed if (A) the program only honored high-priority if read from a
trusted file, and (B) if it were set, called pa_raise_priority() before
dropping privileges, with no group check. A trusted file might be one
writeable only by root or by <pulse>.
James F. Carter Voice 310 825 2897 FAX 310 206 6673
UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc at math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key)
More information about the pulseaudio-discuss