[pulseaudio-discuss] PA_REALTIME_GROUP not honored if over 1000

[Jim Carter]

Versions: PulseAudio 0.9.6 on SuSE 10.2, kernel 2.6.18.8
File: /pulseaudio-0.9.6/src/daemon/main.c line 349
Thread reference: 
http://www.redhat.com/archives/fedora-desktop-list/2007-January/msg00091.html

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 
documentation.  

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)