Ticket #21 (closed defect: fixed)

Opened 2 years ago

Last modified 1 year ago

realtime group membership prevents polypaudio to start

Reported by: eric.moret@epita.fr Assigned to: lennart
Priority: normal Milestone: 0.9.6
Component: daemon Severity: major
Keywords: Cc: cj@vdbonline.com

Description

I am running polypaudio 0.9.1 on Fedora Core 5. When my user is not part of group realtime, polypaudio starts and works with no problem but when I am in that group it refuses to do so. What am I doing wrong? 

$ grep prio /etc/polypaudio/daemon.conf
high-priority = 1
$ polypaudio
daemon/main.c: WARNING: called SUID root, but not in group 'realtime'.
polypcore/core-util.c: setpriority(): Permission denied
polypcore/core-util.c: sched_setscheduler(): Operation not permitted
modules/module-alsa-source.c: *** ALSA-XRUN (capture) ***
modules/module-alsa-sink.c: *** ALSA-XRUN (playback) ***
modules/module-alsa-sink.c: *** ALSA-XRUN (playback) ***
$ su -
# groupadd realtime
# gpasswd -a emoret realtime
Adding user emoret to group realtime

Logging out / logging back in for group membership to become active... 

$ polypaudio
daemon/daemon-conf.c: WARNING: failed to open configuration file '(null)': Permission denied

Attachments

pulseaudio_fix21.patch (0.6 kB) - added by rawuza on 02/21/07 21:09:28.
pulseaudio_fix21-2.patch (2.6 kB) - added by rawuza on 02/21/07 22:46:24.

Change History

07/07/06 16:47:50 changed by lennart

  • milestone deleted.

01/10/07 14:15:02 changed by slomo

  • severity changed from normal to major.

I can confirm this here... only chmod -s /usr/bin/pulseaudio fixes this for me but then it obviously won't run as pulse-rt user...

01/26/07 09:14:02 changed by ossman

There were some fixes for this some time ago. Unfortunately they haven't been rolled into a release yet. Could I get you to try compiling from svn and test that?

01/30/07 21:26:12 changed by slomo

This seems to be caused by non-world-readable home directories...

chmod 700 $HOME -> doesn't start chmod 744 $HOME -> starts fine

I'll take a look at SVN later.

02/02/07 22:32:33 changed by cjvdb

  • cc set to cj@vdbonline.com.

Strangely enough, this is caused by pulseaudio *not* dropping priviledges when running suid root and realtime. If the home directory is not world readable then the check in line 956 of src/pulsecore/core-util.c (from 0.9.5) fails and pulseaudio exits. Why pa can't read the home directory while running uid == 0 is beyond me though.

When *not* in the realtime group, pulseaudio drops root privs earlier, before reading the configs, (see src/daemon/main.c:339) and everything is fine.

I would write a patch, but I don't quite get why pa can't read the config in the first place if it's running uid == 0. If anyone could point me to a commit that fixes this I would really appreciate it as I would like to backport it to the debian 0.9.5 package. From a brief browse of truck head it looks like the problem is still there though.

02/05/07 11:27:19 changed by ossman

Terribly sorry, it seems it wasn't fixed after all. Could you try applying r1423?

02/05/07 11:32:49 changed by cjvdb

Do you think r1423 is the right fix? If the user actually *has* a ~/.pulse/default.pa and uses suid+realtime+non-worldreadable-home it'll still break because pa will give up and read /etc/pulse/default.pa instead.

(follow-up: ↓ 9 ) 02/05/07 16:44:13 changed by ossman

It is part of the solution anyway. It shouldn't abort when it can't read the user config, no matter the reason.

As for the case of root not being able to read it, it should only appear with nfs root-squash (or similar) and requiring a+x in that case is not the end of the world. The config file shouldn't contain security sensitive information. A solution that handles all cases would be incredibly complex (e.g. the global conf might only be readable by root). Ideas welcome though.

(in reply to: ↑ 8 ; follow-up: ↓ 10 ) 02/05/07 17:11:18 changed by cjvdb

Replying to ossman:

It is part of the solution anyway. It shouldn't abort when it can't read the user config, no matter the reason.

Ok, that makes sense.

As for the case of root not being able to read it, it should only appear with nfs root-squash (or similar) and requiring a+x in that case is not the end of the world. The config file shouldn't contain security sensitive information. A solution that handles all cases would be incredibly complex (e.g. the global conf might only be readable by root). Ideas welcome though.

Wouldn't dropping root filesystem access rights with setfsuid before reading the config files be the correct solution? (in addition to r1423) That seems like the most obvious behaviour to me. After all, if the global config is only readable by root then the admin probably doesn't want it to be read by a user startable daemon anyway. And besides, that's effectively what pa does in the suid+non-realtime case now because it drops root entirely before reading configs.

02/21/07 21:09:28 changed by rawuza

  • attachment pulseaudio_fix21.patch added.

(in reply to: ↑ 9 ; follow-up: ↓ 11 ) 02/21/07 21:10:14 changed by rawuza

Strange that noone cared about this, as it prevents you from using rt priority (except if you make you home dir world readable which wouldn't be such a good idea)

As for the case of root not being able to read it, it should only appear with nfs root-squash (or similar) and requiring a+x in that case is not the end of the world. The config file shouldn't contain security sensitive information. A solution that handles all cases would be incredibly complex (e.g. the global conf might only be readable by root). Ideas welcome though.

Point is, all caps are dropped, including CAP_DAC_READ_SEARCH, thus euid = 0 doesn't have permissions to access files not readable by root.

Wouldn't dropping root filesystem access rights with setfsuid before reading the config files be the correct solution?

setfsuid is linux only. So it would break portability. It's better to return to real uid right after setting capabilities. I've attached a patch that works for me.

(in reply to: ↑ 10 ; follow-up: ↓ 12 ) 02/21/07 21:27:44 changed by rawuza

Replying to rawuza:

I've attached a patch that works for me.

Sorry, that was a bit premature. Turns out it doesn't work after all (setpriority(): permission denied).

Another solution is to keep CAP_DAC_READ_SEARCH. But then every file could be read, which might be a secuirity risk.

(in reply to: ↑ 11 ) 02/21/07 22:46:02 changed by rawuza

Another patch is appended. It drops root privileges at the very beginning and regains them for just a very short time to set the priority. After that root is dropped completely.

Would be nice, if you could include the patch in upstream.

02/21/07 22:46:24 changed by rawuza

  • attachment pulseaudio_fix21-2.patch added.

05/23/07 17:42:30 changed by lennart

  • status changed from new to assigned.
  • milestone set to 0.9.6.

05/24/07 15:49:57 changed by lennart

Hmmm. I think a better fix for this is to use prctl(PR_SET_KEEP_CAPS) and change uids entirely while keeping the NICE capabality.

Another possible fix is to make use of the saved uid. i.e. set euid to the uid immediately, leaving the saved uid as 0, and then when we actually need that set euid to the saved uid.

I will look into this.

05/25/07 22:35:31 changed by lennart

  • status changed from assigned to closed.
  • resolution set to fixed.

(In [1455]) when called with the setid bit change euid to uid sooner to make sure that we can access our own files even when we dropped most capabilities. (Closes #21)