Bug 1212503

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.