[pulseaudio-discuss] --check option seems not to work from su(1)

[Tanu Kaskinen]

On Sat, 2014-09-27 at 10:00 -0600, Glenn Golden wrote:
> Coming down the home stretch pestering you guys with pa_context_connect()
> questions.  Hopefully this is the last set, please bear with me.
> 
> Begin with:
> 
>   * XDG_RUNTIME_DIR unset
>   * PULSE_AUDIO envar unset
>   * PULSE_AUDIO X11 property unset

I guess you mean PULSE_SERVER, not PULSE_AUDIO?

>   * default-server in ~/.config/pulse/client.conf is null
>   * autospawn = no (in ~/.config/pulse/client.conf)
>   * No PA server is running
>   * ~/.config/pulse contains only client.conf, no other files or dirs
>   * There are no extant directories named /tmp/pulse*
> 
> Now with an instrumented version of pactl (which dumps server_list), and as a
> non-root user, run
> 
>     $ PULSE_LOG=5 pactl info 
> 
> and see that it constructs server_list with "/tmp/pulse-XXXX/native" as the
> first (user PAS) entry, where XXXX is a 12-charater hash. (The second entry
> is for the [non-existant] system instance; let's ignore that, it's not relevant
> to what follows.)
> 
> Pactl then tries to connect to the user PAS via the above socket path. This of
> course fails, since there's no server running, and pactl complains and exits
> as expected.
> 
> Afterwards, the observed file situation is:
> 
>   * ~/.config/pulse contains a newly-created symlink
> 
>       HOST-runtime -> /tmp/pulse-XXXX
> 
>     where HOST is the hostname on which pactl was executed. 
> 
>   * /tmp now contains a newly created empty directory /tmp/pulse-XXXX.
> 
> 
> Several questions arise:
> 
>   1.  Why is it _creating_ a new runtime dir /tmp/pulse-XXXX (and associated
>       symlink in ~/.config/pulse) when it seems like what it ought to be doing
>       in this situation is simply looking for an extant runtime dir (given that
>       autospawn is disabled)?

The function for getting the runtime dir also creates it if it doesn't
exist. I don't think that's a good idea, but that's how Lennart did it
in the beginning of time and nobody has bothered to changed it.

>   2.  Why does it name the symlink in ~/.config/pulse as HOST-runtime, rather
>       than MID-runtime (since on my system /etc/machine-id is available)?

Most likely because you built pulseaudio from source and sysconfdir
points to /usr/local/etc, hence pulseaudio doesn't search the machine-id
file from /etc. We should probably try the hardcoded path
of /etc/machine-id if the file can't be found under sysconfdir. In the
meanwhile, you can pass "--sysconfdir=/etc" to the configure script (or
use bootstrap.sh, which calls configure with "--sysconfdir=/etc" by
default).

>   3.  What information participates in the hashing that generates the XXXX?
>       (The reason for this question is that it seems to generate identical XXXX
>       every time, if one starts with the initial conditions described above.)

It's not a hash, it's a pseudo-random string. It seems that the seed
isn't set by libpulse, it's only set by the daemon, so if a client
creates the "random" directory, it will always be the same, because the
seed will always be 1 (we use rand() for randomness).

This looks like a potential security bug, because some other user can
create the directory first. Luckily, it seems that if the random
directory already exists, we will not try to use it, but we will try
again with a different directory, so it's not a simple DoS attack, nor
is it possible to fool PulseAudio into using a directory with malicious
contents. The subsequent directories will be guessable too, though, so
it is possible to slow down PA clients by creating a huge amount of
pre-created directories in /tmp.

>   4.  In the constructed server_list, it seems curious that it contains the
>       dereferenced symlink (i.e. the target directory /tmp/pulse-XXXX/native)
>       rather than the symlink itself (~/.config/pulse/HOST-runtime).  (This is
>       a minor point; just asking because seems to me that the symlink is the
>       more useful piece of info to be reported when debug logging is enabled,
>       since in effect, that's the runtime dir of interest.)

prepend_per_user() in context.c calls pa_runtime_path(), which will
return a string containing the runtime directory concatenated with
another path, in this case "native". pa_runtime_path() in turn calls
get_path() in core-util.c, and get_path() resolves the symlink, because
we had an issue on some systems with the non-resolved path being too
long (over 108 characters). The resolved path is likely to be shorter
than the non-resolved path.

-- 
Tanu