--check option seems not to work from su(1)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2014-08-21 at 16:55 -0600, Glenn Golden wrote:
> A side issue that I came across, related to the --check option, but not the
> doc issue itself:
> 
> Suppose the root user wishes to use the --check option to see if user xyz
> has a PA daemon running. He does this:
> 
>     #  XDG_RUNTIME_DIR=/run/user/1234  pulseaudio --check -v
> 
> which dutifully reports (correctly) that "Daemon running as PID xxx".  But
> it also has the silent side effect that the directory /run/user/1234/pulse is
> chowned to root.root, thus preventing user xyz from further communication
> with the daemon due to accesss permission violation.
> 
> Two questions:
> 
>   * Can you reproduce this?
>   * What is your view as to whether this is a bug? (IMO it is, and was going
>     to report it, but wanted to hear your view.)

It's not a bug, because --check isn't documented to be a tool for
checking if other users' daemons are running. If such functionality is
useful for people, then maybe we should extend the scope of --check, but
setting XDG_RUNTIME_DIR to point to another user's directory seems like
a hack to me, because it's against the usual semantics of the variable.
If there is some API for querying the runtime directory of arbitrary
users, we could implement this e.g. by adding --check-for-user=foo, but
I'm not aware of such API. In my opinion, such system API is necessary
before we should officially support this use case for --check.

I'm not against making this an undocumented feature, though, if it turns
out that there's no good reason to chown the runtime directory when
running --check. If the user's intention is to check the status of
another user's pulseaudio, then the chowning is of course unnecessary
and harmful, but if the user's intention is to check whether his/her own
pulseaudio is running, then it's perhaps a different situation. We need
to understand why the runtime directory is ever chowned. I don't see
very good reasons for that myself, but on the other hand, I'm hesitant
to change that without understanding the original motivation.

-- 
Tanu



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux