Pulse + su + autospawn = root perms on /tmp/pulse-$USER

[coling]

This is a report inspired by a Mandriva bug report that I have now replicated myself.

To replicate:

1. As a regular user start pulseaudio normally (e.g. pulseaudio -vvv).
2. su (do not su -)
3. Edit /etc/pulse/client.conf and ensure autospawn = no
4. Check perms on /tmp/pulse-$USER (ls -ld /tmp/pulse-$USER)
5. paplay filename.wav (pick something ;))
6. Check perms on /tmp/pulse-$USER (ls -ld /tmp/pulse-$USER)
7. It should at this stage still be owned by $USER
8. Edit /etc/pulse/client.conf and ensure autospawn = yes
9. paplay filename.wav
10. Check perms on /tmp/pulse-$USER (ls -ld /tmp/pulse-$USER)
11. The above check should reveal user and group ownership of root. Ooops. $USER can no longer play sound :(

[coling]

Note: when using su - I was aple to play the sounds fine and they just seemed to be routed to $USER's pulseaudio instance (I guess because the X11 cookie...)

It may be that pulse should not run when under su or sudo? Or perhaps this is a bug in the autospawning code?

[coling]

I think that this issue stems from the output of the function pa_get_user_name in [source:trunk/src/pulse/util.c@#L67]. On my system when I do a plain su $USER == my original username, not "root".

I've confirmed this via a small test app:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main()
{
  uid_t uid = getuid();
  gid_t gid = getgid();
  
  printf("%d - %d\n", uid, gid);
  
  char *p;
  if (!(p = getenv("USER")) && !(p = getenv("LOGNAME")) && !(p = getenv("USERNAME")))
  {
    printf("Not got env....\n");
  }
  else
  {
    printf("Found %s from env\n", p);
  }
  return 0;
}

This produces the following output:

[colin@jimmy pulseaudio]$ g++ -o test test.c
[colin@jimmy pulseaudio]$ ./test
603 - 603
Found colin from env
[colin@jimmy pulseaudio]$ su
Password: 
[root@jimmy pulseaudio]# ./test
0 - 0
Found colin from env
[root@jimmy pulseaudio]# exit
[colin@jimmy pulseaudio]$ sudo -s
[root@jimmy pulseaudio]# ./test
0 - 0
Found root from env
[root@jimmy pulseaudio]# exit
[colin@jimmy pulseaudio]$ pwd
/home/colin/Development/Personal/Checkouts/pulseaudio
[colin@jimmy pulseaudio]$ su -
Password: 
[root@jimmy ~]# cd /home/colin/Development/Personal/Checkouts/pulseaudio
[root@jimmy pulseaudio]# ./test
0 - 0
Found root from env
[colin@jimmy pulseaudio]$ sudo -i
[root@jimmy ~]# cd /home/colin/Development/Personal/Checkouts/pulseaudio
[root@jimmy pulseaudio]# ./test
0 - 0
Found root from env

As can be seen from the above, su is the only one of the four commands that does not set $USER to "root".

I have tested this on a Mandriva Cooker system and on a CentOS 5 system with the same results. I've yet to try on any other distros.

Col

[coling]

Incidentally I seem to be able to replicate this simply by running pulseaudio as root under a su session:

[colin@jimmy pulseaudio]$ ll -d /tmp/pulse-colin
drwx------ 2 colin colin 4096 2008-01-12 11:38 /tmp/pulse-colin/
[colin@jimmy pulseaudio]$ su
Password: 
[root@jimmy pulseaudio]# pulseaudio
W: main.c: This program is not intended to be run as root (unless --system is specified).
E: pid.c: Daemon already running.
E: main.c: pa_pid_file_create() failed.
[root@jimmy pulseaudio]# ll -d /tmp/pulse-colin
drwx------ 2 root root 4096 2008-01-12 11:38 /tmp/pulse-colin/

So the whole autospawn thing is not specific to this problem but it clearly makes it more likely to happen automatically.

NB passing -vvv didn't give any more useful info in the output.

[coling]

I think I've addressed this by swapping the order the environment variables are checked. This may not work on all systems as I think Sjored said on IRC that his $USER and $USERNAME are the inverse of mine under a su session.

See patch here.

[lennart]

Closing now. If you start PA from su, then you get what you deserve. Also, if there's something to fix, then probably in su, not so much in PA.