The epam binary needs to be installed setuid root so that it can read /etc/shadow for pam authentication. This is documented upstream at https://docs.ejabberd.im/admin/guide/configuration/#pam-authentication. The version of ejabberd distributed with Fedora 22 and Fedora 23 had a patch to install this binary this way, but that patch was dropped when we released Fedora 24. This bug was originally reported in the comments of #1337216[0]. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1337216
Created attachment 1196590 [details] p1_pam patch for the facl solution One of the challenges with making this change is that there's a slight chicken and egg problem. We need to set the epam binary to mode 4750 (we don't want just any user executing it), which means that we want to set the group to ejabberd so that the ejabberd user can execute it. However, this erlang-p1_pam package is a dependency of the ejabberd package which means that the ejabberd user/group won't exist when erlang-p1_pam is installed. I considered having the p1_pam package create the ejabberd group if the group doesn't already exist, and we could solve this problem that way. p1_pam is currently only used by ejabberd so it wouldn't be that dirty. However, the upstream package is separated from ejabberd, presumably because they want it to be generally useful so it does seem strange for it to create an ejabberd group. Another option is to set the epam binary mode to 4700, but then have the ejabberd package set a facl on it that gives the ejabberd user the rx bits. This is a little strange as well, since it also seems wrong for a package to modify an artifact of another package. I lean towards the facl solution, but I'm interested in hearing some input from others. I'm attaching an extremely simple patch that would be applied to p1_pam for the facl solution, but if we go this route there would also be a required change to ejabberd so that it sets the ejabberd rx facl upon install. I've also considered that perhaps it makes sense to leave this problem up to the end user to solve, and deliver documentation about the various options. I think I lean away from doing it this way and towards solving it automatically through one of the above, but I thought it was worth consideration nonetheless.
I decided to write the fedora-devel mailing list to get their input on how to best solve this chicken and egg problem[0]. While writing that post, I realized that there was a problem with the plan to use facls: if the p1_pam package were updated after the ejabberd package set the needed facls on the binary, the facls would be removed and the problem would return. Thus, I don't think that's a viable option. Perhaps having p1_pam create the ejabberd group is the best alternative I've thought of so far, but I'll be interested to see if we get any replies on the devel list. [0] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/HJNJ3Q24T6NFQ2E3UWUPQYVYKQ2S3DBY/
Fixing this sounds more complicated than I currently have time for, so I will unfortunately have to put this down for now. I think the best thing is to work with upstream ejabberd to make it compatible with sssd as well. It doesn't seem like a good idea for the distribution to setuid root on this library for all users, and doing so only for ejabberd is complicated.
I am going to fix this in Rawhide, with erlang-p1_pam-1.0.3-1.fc27. With that build, upstream has made the so be SUID in the installer.
Well, it turned out that I actually did this myself in the specfile and just forgot to close this bug. It was fixed in erlang-p1_pam-1.0.0-3.fc26.
And to be even more confusing, I did not release the fix to this. I think I just had a stale change to my spec file on my machine that corresponded to the version in F26 that made me think this. I confirmed that F26 is not suid root.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. 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 '24'. 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 24 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 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 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.