[pulseaudio-discuss] PA_REALTIME_GROUP not honored if over 1000

[Lennart Poettering]

On Fri, 27.07.07 21:53, Jim Carter (jimc at math.ucla.edu) wrote:

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

This was intended to be a protection against misuse of this
feature. Maybe it wasn't such a good idea.

Background of this is that most unixes/linuxes know system groups and
non-system groups. The former have the first couple of hundred GIDs,
the latter use the rest. pulse-rt should be a system group, not a user
group, thus this protection. (i.e. a group limited to the same system,
not shared across the network using NIS or suchlike)

I guess the biggest mistake was to assume that 1000 was the GID where
the user groups start. But actually, as you noticed it is 500 on
Fedora and other systems. It is also what the LSB says:

http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/uidrange.html

I have now posted a bug about this, to keep track:

http://pulseaudio.org/ticket/111

I wonder though how much value there still is in the pulse-rt stuff
given that we now have the ability to set rt privs via PAM.

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

Actually, while I agree that the documentation on PA could use a lot
of improvement this particular behaviour *is* documented. In FAQ #11:

http://pulseaudio.org/wiki/FAQ

(Yeah, I admit this might be difficult to find, if one doesn't look
for the exact same question listed in the FAQ.)

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

Something like this is basically what the PAM rt stuff provides in
/etc/security/limits.conf.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4