This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

We should review polkit rules again.

This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

The /usr/share/polkit-1/actions/ejabberdctl.policy file does have allow_any set to no, but it also has allow_inactive and allow_active set to auth_self. By my reading of some Arch documentation[0] I found about policykit, this means that ssh and physical users should both have to authenticate to run ejabberdctl. Setting one or both of those values to yes would allow those users to execute the command without authenticating.

In either case, even the root user cannot meaningfully use ejabberdctl without being the ejabberd user, as there is a /var/lib/ejabberd/.erlang.cookie file that is needed to connect to the running ejabberd daemon. Since that file isn't in the root user's home folder, it is not found. When I use the utility on my own system, I typically have to do something like this:

sudo -u ejabberd /bin/sh /usr/bin/ejabberdctl <command>

Peter, do you know a way to work around that so that any properly authenticated user (root, me, etc.) can find that .erlang.cookie file automatically? I found some documentation that seems to indicate that the cookie is searched for at $HOME[1], and it suggests that copying the cookie to other places might be a reasonable way to proceed. There is also a -setcookie parameter for /usr/bin/erl, but I think it might not be related to the path of the cookie but rather its value.

If we can't have a way for other users (including root) to be able to access this cookie, it seems to me that having a policykit policy at all does not make much sense since the ejabberdctl has to always be run as the user that started the daemon. That is, unless users know to copy that cookie around, in which case they should also know they could write their own policykit rules (or use sudo).

What do you think?


[0] https://wiki.archlinux.org/index.php/Polkit#Actions
[1] http://erlang.org/doc/reference_manual/distributed.html#id88336
[2] http://erlang.org/doc/man/erl.html

I have resolved the issue I referred to where users had to use the -u ejabberd flag in a recent update for F25 and Rawhide, but I still am not sure what to do about the policykit issue here. What is the value in using policykit with ejabberdctl when a sudoers file can be used to control access? Policykit does seem valuable to be on a Desktop system, but I'm not sure how it is useful for a server like ejabberd. I'm leaning towards removing the policykit integration since I'm not very familiar with it, but if someone can make a case for keeping it I'm interested to listen!

AIUI, allow_active and allow_inactive are both only for local sessions, active if that's the session currently being displayed on the screen, inactive if it is in the background (think user switching). SSH sessions are allow_any.

Also, defaulting to auth_self is very useless, because it allows any local user to run the daemon! This needs to be set to auth_admin (which will allow their own password only to wheel users, the others need the root password).

Kevin, do you think there is a use case for keeping ejabberd with auth_admin, or do you think sudo is sufficient?

I started a thread on fedora-devel about the usefulness of keeping policykit integration for ejabberd, but it's gotten no replies so far:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/HLVK5YP3NMDKJCYNFHXXPCPAOELZI6OC/#HLVK5YP3NMDKJCYNFHXXPCPAOELZI6OC

I'm going to adjust all three to be auth_admin.

ejabberd-16.09-5.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-5d9f0a5954

ejabberd-16.09-5.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-5d9f0a5954

ejabberd-16.09-5.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.