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

[Glenn Golden]

Tanu Kaskinen <tanu.kaskinen at linux.intel.com> [2014-08-20 13:26:19 +0300]:
>
> (added pulseaudio-discuss back to CC)
> 
Thx, I hit the wrong button on the reply earlier.

>
> On Tue, 2014-08-19 at 16:26 -0600, Glenn Golden wrote:
> > This is completely misleading: The test that is performed by the --check
> > option evidently has _nothing whatsoever_ to do with the "calling user",
> > it is determined entirely by the XDG_RUNTIME_DIR envar, regardless of the
> > user who executed the "pulaseaudio --check" command.  The blurb should
> > simply state that the check is performed based on the user whose runtime
> > pid dir is pointed to by XDG_RUNTIME_DIR, and then it will be entirely
> > accurate and complete.
> 
> I'd rather say that the check is performed with the assumption that
> XDG_RUNTIME_DIR is set correctly for the calling user.
>

But that phrasing simply introduces a subtler ambiguity: What does "set
correctly" mean in the context of a calling user who has used (e.g.) su(1)
or runuser(1) or an SUID executable to switch UID or EUID?

Example: A process can be running with UID = xyz, EUID = 0, and so accesss
would be allowed to all /run/user/* directories, not just the directory of
user xyz.  Who is the "correct" user in this situation?

Otoh, simply stating that "the test is performed based on XDG_RUNTIME_DIR"
without any further qualification provides the reader with both the necessary
and sufficient information to inform him as to how the check is performed.
Let the reader infer what he wishes about the notion of "correctness" of
the setting of XDG_RUNTIME_DIR in his particular situation.

>
> The check is non-functional if XDG_RUNTIME_DIR points to the wrong directory,
> because the answer will always be "not running", because most likely
> pulseaudio won't have access to the directory that XDG_RUNTIME_DIR points to.
> 

Exactly. So wouldn't it make sense to say just state that in the doc? 

     "The check is performed based on the runtime directory specified by
      $XDG_RUNTIME_DIR. If this envar points to a directory which is not
      accessible to the process owner, then the return code is undefined."

(Or perhaps "non-zero" instead of "undefined" above, if that is the case.)

>
> Also, if you're going to mention XDG_RUNTIME_DIR in the documentation,
> you should probably also mention that if XDG_RUNTIME_DIR isn't set at
> all, then the check assumes that HOME[1] is set correctly.
> 

The above does not seem to be the case on my Arch linux setup: In the following
example, the PA daemon is running as user gdg, and yet:

    # id
    uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys), \
	4(adm),6(disk),10(wheel),19(log)

    # su - gdg
    $ id
    uid=501(gdg) gid=501(gdg) groups=501(gdg),19(log),92(audio), \
	190(systemd-journal)
    $ unset XDG_RUNTIME_DIR
    $ echo $HOME
    /home/gdg
    $ pulseaudio --check -v
    I: [pulseaudio] main.c: Daemon not running

>From an xterm which is directly logged in as user gdg, the --check option
correctly reports the daemon info:

    $ id
    uid=501(gdg) gid=501(gdg) groups=501(gdg),19(log),92(audio), \
	190(systemd-journal)
    $ echo $HOME
    /home/gdg
    $ echo $XDG_RUNTIME_DIR
    /run/user/501
    $ pulseaudio --check -v
    I: [pulseaudio] main.c: Daemon running as PID 29731

So... before I submit a doc patch, it would probably be worthwhile to get
hold of a confirmed explanation of exactly what is being done for the check.

If you can point me to a sourcefile, I'll try to plumb the details myself,
and then get back to you with my findings and see if you agree before
submitting a doc patch.

Thanks,

Glenn