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

[Tanu Kaskinen]

On Fri, 2014-08-22 at 05:55 -0600, Glenn Golden wrote:
> 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]:
> > > > 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.

Fair point, "correctly set" isn't really informative enough. I'm just
afraid that the documentation will promise too much about the current
implementation in a way that will prevent us from ever changing the
logic. It's probably necessary to explain some of the details how
XDG_RUNTIME_DIR and HOME are used, but it would be good to make it clear
that it's just the current implementation for finding the answer to the
question "is pulseaudio running for the current user", and it might
change some day (not that I currently see any reason to change it). As a
sidenote, by I wonder what happens if you run --check as a regular user
when pulseaudio has been configured to run in the system mode... It
seems probable that it will return "not running", which would be a bug
IMO.

-- 
Tanu