SSSD upstream allows running as non-root for some time. When Fedora packages the next SSSD version (1.13), it should switch to running as non-root by default.
What we could do here is the same we do in RHEL. It would require us to carry additional patch, but the patch is trivial.
This bug needn't improve security because enabling running sssd as non-root user requires binaries with set suid bit, which can decrease security
Moving to rawhide because coredumps cannot be caught due to calling setuid)(), setgid(). And t does not depend on abrt; coredumps canot be caught even with systemd/coredumpctl
*** Bug 1290745 has been marked as a duplicate of this bug. ***
Lukas preventing catching crashes by default is a *good* thing. coredumps may contain passwords of users and shouldn't happen unless the admin explicitly configures the system to allow setuid applications to core dump IMO. I do not think this intentional restriction should hold up this bug.
man proc -> /proc/sys/fs/suid_dumpable says: 2 ("suidsafe") Any binary which normally would not be dumped (see "0" above) is dumped readable by root only. This allows the user to remove the core dump file but not to read it. For security reasons core dumps in this mode will not overwrite one another or other files. This mode is appropriate when administrators are attempting to debug problems in a normal environment. Additionally, since Linux 3.6, /proc/sys/kernel/core_pat‐ tern must either be an absolute pathname or a pipe com‐ mand, as detailed in core(5). Warnings will be written to the kernel log if core_pattern does not follow these rules, and no core dump will be produced. Even thought there might a password in coredump it should be safe according to the manual page. Unless the man page does not reflect current state in kernel. a) Such change require a lot of testing. I do not want to use fedora users as a testers. We already have many test which could be used. There just need to be reserved time for it; which I do not have ATM. b) Even though we test sssd before releasing to fedora there are still corner cases which cause crashes e.g BZ1269232. Without abrt we might not need to catch them because the main process would restart responder or back-end after crash. The fast fix would mean: untested sssd (maybe many bug reports) + missing crash reports. I'm sorry it's a disadvantage for me rather than an advantage. BTW: There is a plan for creating rules for openSCAP. https://fedorahosted.org/sssd/ticket/2847 So might add such rule there.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
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.