> I think abrt should figure out if the crashing binary is part of
Would it be an option to create your own configuration for libreport?
It is much simpler and robust to deliver a config tailored for your
packages than trying to generalize the task and define a global policy
Example:
cat >/etc/libreport/events.d/my_system_service.conf <<EOF
EVENT=post-create executable=/usr/sbin/my_system_service
journalctl -u my_system_service > my_system_service.log
EOF
> Could we have a per-service switch that says
Unfortunately, I am not sure we can say that a coredump file
never contains any security sensitive data. For example, it contains
a copy of /proc/[pid]/environ and if not cleared and an admin has
a strange idea to export a crazy stuff, we are in trouble.
Jakub
On Mon, Apr 08, 2019 at 02:21:47PM +0200, jfilak@xxxxxxxxxxxxxxxxx wrote:
> I agree, but the file /proc/meminfo is not present, right?
> And yes, the abrt thing just reads the data from journal and
>
> stores them on filesystem to be able to upload them to Bugzilla.
>
>
>
>
>
> Regarding the missing logs, the journal log lines should
>
> be extracted by this thing:
>
> https://github.com/abrt/abrt/blob/master/src/plugins/ccpp_event.conf#L25
> (https://github.com/abrt/abrt/blob/master/src/plugins/ccpp_event.conf#L25)
>
> which is a little bit complex, so no wonder if it is broken
Thanks for the link. That code boils down to
"journalctl -q -b --since=-3m --system -n 99 _COMM="$base_executable"
and for systemd services this is very underwhelming, because it doesn't
use the information that the process is part of service, and all logs
from that service are relevant, e.g. when it launches a second
executable or switches uid.
I think abrt should figure out if the crashing binary is part of a
system service, and switch to a log collection mode that is more like
'journalctl -u' in this case. Also, don't limit the messages to just 3
minutes or 99 messages.
> (I am just not sure why the abrt test suite is not failing though).
>
> Regarding the core files, I was under the impression that
> the core files can be attached only if the reporter wants to attach it.
> IOW the core files were never attached automatically (due to security
> issues).
Could we have a per-service switch that says "this service never has
private information, make the coredump file collection opt-out"?
For example, we get a number of reports for systemd-logind, and by
design it never has any private user data or keys. The user interface
could be simplified. Similarly for hwrngd, and probably many others.
> If you need some information that is relevant only to your packages,
> we can work together to create a new abrt configuration which will
> gather that information for your packages
> (for example, dnf ships its own abrt configuration).
Can you point me to it? rpm -ql $(rpm -qa|grep dnf)|grep abrt doesn't
yield anything.
Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
