Hide Forgot
Description of problem: polkitd is repeatedly segfaulting on my system (see bug 910262) and abrt is not detecting it or offering to file a report Version-Release number of selected component (if applicable): abrt-2.1.9-1.fc19.x86_64 How reproducible: Every time (assuming polkitd is terminating). Reports like this in dmesg: [23241.640778] traps: polkitd[841] general protection ip:7f9611b509d2 sp:7fff59014920 error:0 in libmozjs-17.0.so[7f9611a19000+3a7000] [34947.361757] traps: polkitd[13497] general protection ip:7f877fe409d2 sp:7fff3865ba80 error:0 in libmozjs-17.0.so[7f877fd09000+3a7000] [46952.438198] traps: polkitd[18531] general protection ip:7fad8083a9d2 sp:7fff983fc730 error:0 in libmozjs-17.0.so[7fad80703000+3a7000] [58957.869501] traps: polkitd[29385] general protection ip:7f60645879d2 sp:7fff91522d80 error:0 in libmozjs-17.0.so[7f6064450000+3a7000] and in journalctl: Nov 06 09:10:01 eng1n65.eng.sedsystems.ca systemd[1]: polkit.service: main process exited, code=killed, status=11/SEGV Nov 06 09:10:01 eng1n65.eng.sedsystems.ca systemd[1]: Unit polkit.service entered failed state. Steps to Reproduce: 1. 2. 3. Actual results: User is not notified of polkitd crash and it does not show up in the ABRT applet. Crashes in other components do appear to get detected. Expected results: ABRT detects a crash and offers to report it Additional info:
Seeing abrt not reporting polkitd crashes to me either on f20.
Thanks for your report. Please check the value in /proc/sys/fs/suid_dumpable. If it is zero (default), then this looks like a correct behavior. polkitd uses setuid() or similar to drop privileges and doing that disables coredumping for the given process (for security reasons). If you want to enable coredumping anyway, you need to set the value of fs.suid_dumpable to either 1 or 2. 'man 5 proc' gives more details: /proc/sys/fs/suid_dumpable (since Linux 2.6.13) The value in this file determines whether core dump files are produced for set-user-ID or otherwise protected/tainted binaries. Three different integer values can be specified: 0 (default) This provides the traditional (pre-Linux 2.6.13) behavior. A core dump will not be produced for a process which has changed credentials (by calling seteuid(2), setgid(2), or similar, or by executing a set-user-ID or set-group-ID program) or whose binary does not have read permission enabled. 1 ("debug") All processes dump core when possible. The core dump is owned by the file system user ID of the dumping process and no security is applied. This is intended for system debugging situations only. Ptrace is unchecked. 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.
Confirmed that setting suid_dumpable=2 allows abrt to detect and report the crash (see bug 1048296). Ideally there should be some way to detect that this kind of crash happened and at least notify the user that something is happening, but I'm not sure this is something that abrt is able to do if no core file is generated at all.
Thanks, right I'll set it at '1' on my machine and see what we sweep up. Given that this stuff is going through abrt-hook-ccpp I could see an argument that says as long as it knows that the program is priveliged (does it?) then it could do the safe thing and treat it like a root program crashing, so maybe as long as we know we're always going via abrt-hook-ccpp then it's safe to select 1 or 2 in suid_dumpable. Curiously cat /proc/sys/kernel/core_pattern shows: [dg@major ~]$ cat /proc/sys/kernel/core_pattern |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e I'd have thought that would be %e at the end?
(In reply to rh from comment #4) > Thanks, right I'll set it at '1' on my machine and see what we sweep up. > Given that this stuff is going through abrt-hook-ccpp I could see an > argument that says as long as it knows that the program is priveliged (does > it?) then it could do the safe thing and treat it like a root program > crashing, Yes, ABRT works exactly like that: https://github.com/abrt/abrt/blob/master/src/hooks/abrt-hook-ccpp.c#L566 > so maybe as long as we know we're always going via abrt-hook-ccpp > then it's safe to select 1 or 2 in suid_dumpable. > > Curiously cat /proc/sys/kernel/core_pattern shows: > [dg@major ~]$ cat /proc/sys/kernel/core_pattern > |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e > > I'd have thought that would be %e at the end? If ABRT is sure that %e is supported, it uses %e at the end :) https://github.com/abrt/abrt/blob/master/src/hooks/abrt-install-ccpp-hook.in#L13
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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 19 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.
This problem is still occurring in F21. polkit is still terminating periodically and abrt does not detect it.
I could confirm that : Mar 16 16:01:02 segulix kernel: traps: polkitd[6934] general protection ip:7fccde9a9de2 sp:7fff98f8d5e0 error:0 in libmozjs-17.0.so[7fccde86a000+3ba000] Mar 16 16:01:02 segulix systemd[1]: polkit.service: main process exited, code=killed, status=11/SEGV Mar 16 16:01:02 segulix systemd[1]: Unit polkit.service entered failed state. Mar 16 16:01:02 segulix systemd[1]: polkit.service failed. Mar 16 16:01:02 segulix NetworkManager[961]: <warn> error requesting auth for org.freedesktop.NetworkManager.settings.modify.hostname: (4) GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) Mar 16 16:01:02 segulix NetworkManager[961]: <warn> error requesting auth for org.freedesktop.NetworkManager.settings.modify.own: (4) GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) Mar 16 16:01:02 segulix NetworkManager[961]: <warn> error requesting auth for org.freedesktop.NetworkManager.settings.modify.system: (4) GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) Mar 16 16:01:02 segulix NetworkManager[961]: <warn> error requesting auth for org.freedesktop.NetworkManager.wifi.share.open: (4) GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) Mar 16 16:01:02 segulix NetworkManager[961]: <warn> error requesting auth for org.freedesktop.NetworkManager.wifi.share.protected: (4) GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) Mar 16 16:01:02 segulix NetworkManager[961]: <warn> error requesting auth for org.freedesktop.NetworkManager.network-control: (4) GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) Mar 16 16:01:02 segulix NetworkManager[961]: <warn> error requesting auth for org.freedesktop.NetworkManager.enable-disable-wimax: (4) GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) Mar 16 16:01:02 segulix NetworkManager[961]: <warn> error requesting auth for org.freedesktop.NetworkManager.enable-disable-wwan: (4) GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) Mar 16 16:01:02 segulix NetworkManager[961]: <warn> error requesting auth for org.freedesktop.NetworkManager.enable-disable-wifi: (4) GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) Mar 16 16:01:02 segulix NetworkManager[961]: <warn> error requesting auth for org.freedesktop.NetworkManager.sleep-wake: (4) GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) systemctl status polkit.service ● polkit.service - Authorization Manager Loaded: loaded (/usr/lib/systemd/system/polkit.service; static) Active: failed (Result: signal) since Seg 2015-03-16 16:01:02 WET; 35min ago Docs: man:polkit(8) Main PID: 6934 (code=killed, signal=SEGV)
Still occurs in F22.
(In reply to Robert Hancock from comment #9) > Still occurs in F22. ABRT does not detect polkitd segfaults because it is a protected binary [1]. Perhaps we can make both kernel and users happy by creating ABRT problems without dumping core files for crashes of protected binaries. 1: http://abrt.readthedocs.org/en/latest/faq.html#how-to-enable-dumping-of-setuid-binaries
(In reply to Jakub Filak from comment #10) > (In reply to Robert Hancock from comment #9) > > Still occurs in F22. > > ABRT does not detect polkitd segfaults because it is a protected binary [1]. > Perhaps we can make both kernel and users happy by creating ABRT problems > without dumping core files for crashes of protected binaries. > > > 1: > http://abrt.readthedocs.org/en/latest/faq.html#how-to-enable-dumping-of- > setuid-binaries D'oh, I forgot that ABRT cannot detect crashes of protected binaries because kernel does not even try to execute /proc/sys/kernel/core_pattern when a crash of such a binary occurs if /proc/sys/fs/suid_dumpable == 0.
I just want know what crashed , binary or not , so you mean this should be, almost all, a Firefox crashes with flash plugin or other binary ? But everyone wants know at least what makes this crash .
Would it make sense to set suid_dumpable to 2 by default?
(In reply to Miroslav Lichvar from comment #13) > Would it make sense to set suid_dumpable to 2 by default? I have been thinking about using suid_dumpable == 2 in Rawhide and development releases. However, we must not forget that there were some bugs discovered in abrt and kernel allowing a local user to override any file if suid_dumpable == 2, so we should always use the most secure setup in production releases.
with : fs.suid_dumpable=2 in /etc/sysctl.conf I got abrt of polkit.service but seems is not about one Firefox binary (flash-plugin) , abrt duplicated to bug #1175061
(In reply to Sergio Monteiro Basto from comment #15) > I got abrt of polkit.service but seems is not about one Firefox binary > (flash-plugin) , abrt duplicated to bug #1175061 ABRT ignores crashes of Firefox, because Firefox has own crash reporting, and flash-plugin, because flash-plugin is 3rd party program. You can configure ABRT to stop ignoring these binaries in /etc/abrt/abrt-action-save-package-data.conf
(In reply to Jakub Filak from comment #16) > ABRT ignores crashes of Firefox, because Firefox has own crash reporting, > and flash-plugin, because flash-plugin is 3rd party program. You can > configure ABRT to stop ignoring these binaries in > /etc/abrt/abrt-action-save-package-data.conf with : fs.suid_dumpable=2 in /etc/sysctl.conf I got the abrt ...
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.
(In reply to Miroslav Lichvar from comment #13) > Would it make sense to set suid_dumpable to 2 by default? I tried to propose this change on fedora-devel: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5PMHFNKLSP25DSBTIEZEALHET6N4J7NL/
Reopening because this still seems to be an issue in the default config in F24.
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.