Bug 1094143 - Desktop centric polkit ejabberdctl policy file, prevents server use
Summary: Desktop centric polkit ejabberdctl policy file, prevents server use
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: ejabberd
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Randy Barlow
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1094121
TreeView+ depends on / blocked
 
Reported: 2014-05-05 07:07 UTC by Stef Walter
Modified: 2017-01-05 20:21 UTC (History)
6 users (show)

Fixed In Version: ejabberd-16.09-5.fc26 ejabberd-16.09-5.fc25
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-05 20:21:19 UTC


Attachments (Terms of Use)

Description Stef Walter 2014-05-05 07:07:13 UTC
Description of problem:

The shipped polkit policy is completely desktop-centric and expects that the admin user is logged in a local session (ie: a seat in logind parlance, with a monitor and keyboard).

This prevents DBus API use when logged in via ssh (and using pkttyagent as your polkit agent) or via Cockpit.

The <allow_any> tag in polkit policy applies to non-local sessions. It should be set to something other than 'no' unless the action directly affects hardware of the login seat.

Version-Release number of selected component (if applicable):

2.1.13-7.fc20

Comment 1 Fedora End Of Life 2015-05-29 11:45:48 UTC
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.

Comment 2 Fedora End Of Life 2015-06-29 20:27:32 UTC
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.

Comment 3 Peter Lemenkov 2016-06-06 15:33:24 UTC
We should review polkit rules again.

Comment 4 Jan Kurik 2016-07-26 04:32:58 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Comment 5 Randy Barlow 2016-11-24 20:31:18 UTC
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

Comment 6 Randy Barlow 2016-12-17 18:36:24 UTC
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!

Comment 7 Kevin Kofler 2016-12-18 00:43:49 UTC
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).

Comment 8 Randy Barlow 2016-12-21 22:20:11 UTC
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

Comment 9 Randy Barlow 2016-12-25 16:55:52 UTC
I'm going to adjust all three to be auth_admin.

Comment 10 Fedora Update System 2016-12-25 18:58:16 UTC
ejabberd-16.09-5.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-5d9f0a5954

Comment 11 Fedora Update System 2016-12-27 06:20:04 UTC
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

Comment 12 Fedora Update System 2017-01-05 20:21:19 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.