Tanu Kaskinen <tanu.kaskinen at linux.intel.com> [2014-08-21 15:31:13 +0300]:
> On Wed, 2014-08-20 at 06:15 -0600, Glenn Golden wrote:
> > 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.
>
> Unsetting XDG_RUNTIME_DIR thing didn't work, because the pulseaudio
> instance that was running was started in an environment where
> XDG_RUNTIME_DIR was set, and it was set to point to /run/user/501, so
> that directory was used to store the pid file. When you ran pulseaudio
> --check, XDG_RUNTIME_DIR was not set, so pulseaudio couldn't figure out
> that it should have used /run/user/501 for the runtime directory.
> Instead, --check used
> ~/.config/pulse/f8bba75988c34d26965f9d0486fe30af-runtime, and it didn't
> find the pid file there.
>
OK, understand now (and have looked quickly at the sources too, thanks for the
pointer).
But I think that my initial misunderstanding above suggests again that the
phrase "correctly set" (regarding $HOME, as you mentioned above, or regarding
$XDG_RUNTIME_DIR as you mentioned earlier) is ambiguous and ought to be avoided
in the documentation for --check for just that reason.
Imo, in the absence of language defining what "set correctly" means, even a
conscientious reader could be forgiven for assuming any of the following
meanings (pertaining to $HOME in this case):
* $HOME is "set correctly" if it points to the home dir of the UID of the
"pulseaudio --check" process (i.e. the user who ran the --check command).
* $HOME is "set correctly" if it points to the home dir of the owner of the
PA daemon which the user intends to query for its running-ness.
* $HOME is "set correctly" iff $HOME/.config/pulse/XXXXX-runtime is actually
the directory in which the pid file was created for the daemon that the
user intends to query.
See what I mean? It's like asking for confusion.
I do understand now from your explanation that the third meaning is the
appropriate one (and it makes sense, now that I understand it). But the first
two seem to me to be not-unreasonable assumptions that a reader might make.
And all of the above of course interacts with the readers' knowledge (or lack)
of the XDG Base Directory spec.
Imo, the cleanest way to document --check without over-assuming what the reader
may or may not be aware of regarding the XDG spec is to tersely but accurately
describe the necessary and sufficient conditions for it to return 0, including
a brief explanation of how $XDG_RUNTIME_DIR and $HOME are used to locate the
pid file, and leave it at that. This way, the reader can infer on his own
whether running "pulseaudio --check" within a particular environment is going
to do what he is attempting to use it for.
Anyway... Later today or over the weekend I'll take a shot at a suggested
rewrite of the --check description and post it, see what you think.
I'll also try to include a sentence or two that addresses your recent post
[Fri, 22 Aug 2014 13:12:53 +0300] about --check not being intended for use
by any other than the putative daemon owner, if I can squeeze it in without
turning what was originally two sentences into a Tolstoy novel.
