Description of problem: After updating from F32 to F33, fetchmail called under my own user id from a cron entry stopped working: fetchmail: Cannot find absolute path for fetchmail's home directory. After some digging I found the reason: - My .fetchmailrc as well as my sslcertpath are stored in an encfs-mounted, encrypted directory. The directory belongs to my own user id and is mounted under my own user id. - For some weird reason, /usr/bin/fetchmail, owned by root:mail has the S_ISGID bit set. This in conjunction breaks access to my encfs from fetchmail. Version-Release number of selected component (if applicable): fetchmail-6.4.14-1.fc33.x86_64 How reproducible: Steps to Reproduce: 1. set up encfs encrypted dir under normal user account. 2. mount it via encfs 3. store .fetchmailrc inside this dir. 2. call `fetchmail -f ${encfs_dir}/,fetchmailrc mailentry Actual results: Error message: fetchmail: Cannot find absolute path for fetchmail's home directory. Expected results: fetchmail just working in this scenario, like the 15+ years before. Additional info: This lets fetchmail work normaly again: sudo chmod g-s /usr/bin/fetchmail If the S_ISGID has not been added accidentally to fetchmail for some reason, please find another way to do what this is supposed to do. Please don't break existing scenarios. Corinna
Hi, I'm sorry to hear that the change breaks your use case. It was made deliberately to solve another use case, see rhbz#1619069.
Uhm, ok. But it's not the right solution to just set fetchmail's S_ISGID bit. This just opens a can of worms, as you can see in my case. In the scenario in rhbz#1619069, the admin should make sure the cyrus socket is either created in a directory to which all affected users have access. Alternatively, he should create a new group, e.g. "sasl-users", add all affected users to group "sasl-users", and eventually add the group "sasl-users" socket's parent dir ACL with r-x permission. Both of the above solutions allow the scenario in rhbz#1619069 to work with just admin intervention, without breaking other scenarios. Corinna
Yes, I agree with you. Not only it breaks existing scenarios as I can see now, but it also adds one more S_ISGID binary which doesn't need to be. I'll revert the change. Thank you for reporting the issue.
Great, thanks a lot! Corinna
FEDORA-2020-6ba626cb4f has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6ba626cb4f
FEDORA-2020-6ba626cb4f has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6ba626cb4f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6ba626cb4f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-6ba626cb4f has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.