[Auditbeat] Package: Disable librpm signal handlers #10694
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cwurm
added
bug
review
needs_backport
|
Pinging @elastic/secops |
cwurm
force-pushed
the
package_disable_librpm_signal_handlers
branch
from
01eab52
to
77a855b
Compare
|
I did some testing on Fedora 29 (which has a newer version of librpm) and noticed the code didn't work. So I pushed two more commits:
Together with the changes in #10796 this should hopefully now work on all distros. @adriansr do you mind taking another look? |
cwurm
pushed a commit
to cwurm/beats
that referenced
this pull request
Feb 18, 2019
Disable librpm signal handlers. Resolves elastic#10633. (cherry picked from commit 6fbcbff)
cwurm
added
v7.2.0
and removed
needs_backport
cwurm
pushed a commit
to cwurm/beats
that referenced
this pull request
Feb 18, 2019
Disable librpm signal handlers. Resolves elastic#10633. (cherry picked from commit 6fbcbff)
cwurm
pushed a commit
to cwurm/beats
that referenced
this pull request
Feb 18, 2019
Disable librpm signal handlers. Resolves elastic#10633. (cherry picked from commit 6fbcbff)
cwurm
pushed a commit
that referenced
this pull request
Feb 20, 2019
…S 6.x, 7.x, and Fedora 29 (#10796) Librpm version 4.14.2.1 on Fedora 29 no longer contains the `headerGetEntry` method we are currently using. It was deprecated and then removed in version 4.14 (rpm-software-management/rpm@c68fa9a). Also, the much older version 4.8.0 of librpm on CentOS 6.10 (Final) does not yet contain newer data structures for tags like `rpm_tag_t/rpmTag/rpmTagVal`. This PR makes two changes that should allow this code to work on all three distros (CentOS 6.x, 7.x, Fedora 29 - and hopefully anything in between): 1. Use `headerGetString/headerGetNumber` instead of `headerGetEntry`. 2. Use `int32_t` instead of `rpm_tag_t/rpmTag/rpmTagVal`. Luckily, this seems to work on all three distros. I'd prefer something like a typedef, but unfortunately, C99 does not allow repeating a typedef (C11 does) and so backporting them is not easily possible. It also makes the code more lenient with errors during data collection: Only when no package name can be found do we return an error. Together with #10694 this will hopefully allow RPM package collection to work well.
cwurm
pushed a commit
to cwurm/beats
that referenced
this pull request
Feb 20, 2019
…S 6.x, 7.x, and Fedora 29 (elastic#10796) Librpm version 4.14.2.1 on Fedora 29 no longer contains the `headerGetEntry` method we are currently using. It was deprecated and then removed in version 4.14 (rpm-software-management/rpm@c68fa9a). Also, the much older version 4.8.0 of librpm on CentOS 6.10 (Final) does not yet contain newer data structures for tags like `rpm_tag_t/rpmTag/rpmTagVal`. This PR makes two changes that should allow this code to work on all three distros (CentOS 6.x, 7.x, Fedora 29 - and hopefully anything in between): 1. Use `headerGetString/headerGetNumber` instead of `headerGetEntry`. 2. Use `int32_t` instead of `rpm_tag_t/rpmTag/rpmTagVal`. Luckily, this seems to work on all three distros. I'd prefer something like a typedef, but unfortunately, C99 does not allow repeating a typedef (C11 does) and so backporting them is not easily possible. It also makes the code more lenient with errors during data collection: Only when no package name can be found do we return an error. Together with elastic#10694 this will hopefully allow RPM package collection to work well. (cherry picked from commit e7ea5d7)
cwurm
pushed a commit
to cwurm/beats
that referenced
this pull request
Feb 20, 2019
…S 6.x, 7.x, and Fedora 29 (elastic#10796) Librpm version 4.14.2.1 on Fedora 29 no longer contains the `headerGetEntry` method we are currently using. It was deprecated and then removed in version 4.14 (rpm-software-management/rpm@c68fa9a). Also, the much older version 4.8.0 of librpm on CentOS 6.10 (Final) does not yet contain newer data structures for tags like `rpm_tag_t/rpmTag/rpmTagVal`. This PR makes two changes that should allow this code to work on all three distros (CentOS 6.x, 7.x, Fedora 29 - and hopefully anything in between): 1. Use `headerGetString/headerGetNumber` instead of `headerGetEntry`. 2. Use `int32_t` instead of `rpm_tag_t/rpmTag/rpmTagVal`. Luckily, this seems to work on all three distros. I'd prefer something like a typedef, but unfortunately, C99 does not allow repeating a typedef (C11 does) and so backporting them is not easily possible. It also makes the code more lenient with errors during data collection: Only when no package name can be found do we return an error. Together with elastic#10694 this will hopefully allow RPM package collection to work well. (cherry picked from commit e7ea5d7)
This was referenced Feb 20, 2019
cwurm
pushed a commit
to cwurm/beats
that referenced
this pull request
Feb 22, 2019
…S 6.x, 7.x, and Fedora 29 (elastic#10796) Librpm version 4.14.2.1 on Fedora 29 no longer contains the `headerGetEntry` method we are currently using. It was deprecated and then removed in version 4.14 (rpm-software-management/rpm@c68fa9a). Also, the much older version 4.8.0 of librpm on CentOS 6.10 (Final) does not yet contain newer data structures for tags like `rpm_tag_t/rpmTag/rpmTagVal`. This PR makes two changes that should allow this code to work on all three distros (CentOS 6.x, 7.x, Fedora 29 - and hopefully anything in between): 1. Use `headerGetString/headerGetNumber` instead of `headerGetEntry`. 2. Use `int32_t` instead of `rpm_tag_t/rpmTag/rpmTagVal`. Luckily, this seems to work on all three distros. I'd prefer something like a typedef, but unfortunately, C99 does not allow repeating a typedef (C11 does) and so backporting them is not easily possible. It also makes the code more lenient with errors during data collection: Only when no package name can be found do we return an error. Together with elastic#10694 this will hopefully allow RPM package collection to work well. (cherry picked from commit e7ea5d7)
cwurm
pushed a commit
that referenced
this pull request
Feb 25, 2019
…ode compatible across CentOS 6.x, 7.x, and Fedora 29 (#10907) Cherry-pick of PR #10796 to 6.7 branch. Original message: Librpm version 4.14.2.1 on Fedora 29 no longer contains the `headerGetEntry` method we are currently using. It was deprecated and then removed in version 4.14 (rpm-software-management/rpm@c68fa9a). Also, the much older version 4.8.0 of librpm on CentOS 6.10 (Final) does not yet contain newer data structures for tags like `rpm_tag_t/rpmTag/rpmTagVal`. This PR makes two changes that should allow this code to work on all three distros (CentOS 6.x, 7.x, Fedora 29 - and hopefully anything in between): 1. Use `headerGetString/headerGetNumber` instead of `headerGetEntry`. 2. Use `int32_t` instead of `rpm_tag_t/rpmTag/rpmTagVal`. Luckily, this seems to work on all three distros. I'd prefer something like a typedef, but unfortunately, C99 does not allow repeating a typedef (C11 does) and so backporting them is not easily possible. It also makes the code more lenient with errors during data collection: Only when no package name can be found do we return an error. Together with #10694 this will hopefully allow RPM package collection to work well.
cwurm
pushed a commit
that referenced
this pull request
Feb 25, 2019
…S 6.x, 7.x, and Fedora 29 (#10796) (#10843) Librpm version 4.14.2.1 on Fedora 29 no longer contains the `headerGetEntry` method we are currently using. It was deprecated and then removed in version 4.14 (rpm-software-management/rpm@c68fa9a). Also, the much older version 4.8.0 of librpm on CentOS 6.10 (Final) does not yet contain newer data structures for tags like `rpm_tag_t/rpmTag/rpmTagVal`. This PR makes two changes that should allow this code to work on all three distros (CentOS 6.x, 7.x, Fedora 29 - and hopefully anything in between): 1. Use `headerGetString/headerGetNumber` instead of `headerGetEntry`. 2. Use `int32_t` instead of `rpm_tag_t/rpmTag/rpmTagVal`. Luckily, this seems to work on all three distros. I'd prefer something like a typedef, but unfortunately, C99 does not allow repeating a typedef (C11 does) and so backporting them is not easily possible. It also makes the code more lenient with errors during data collection: Only when no package name can be found do we return an error. Together with #10694 this will hopefully allow RPM package collection to work well. (cherry picked from commit e7ea5d7)
cwurm
pushed a commit
that referenced
this pull request
Feb 25, 2019
…ode compatible across CentOS 6.x, 7.x, and Fedora 29 (#10842) Cherry-pick of PR #10796 to 7.x branch. Original message: Librpm version 4.14.2.1 on Fedora 29 no longer contains the `headerGetEntry` method we are currently using. It was deprecated and then removed in version 4.14 (rpm-software-management/rpm@c68fa9a). Also, the much older version 4.8.0 of librpm on CentOS 6.10 (Final) does not yet contain newer data structures for tags like `rpm_tag_t/rpmTag/rpmTagVal`. This PR makes two changes that should allow this code to work on all three distros (CentOS 6.x, 7.x, Fedora 29 - and hopefully anything in between): 1. Use `headerGetString/headerGetNumber` instead of `headerGetEntry`. 2. Use `int32_t` instead of `rpm_tag_t/rpmTag/rpmTagVal`. Luckily, this seems to work on all three distros. I'd prefer something like a typedef, but unfortunately, C99 does not allow repeating a typedef (C11 does) and so backporting them is not easily possible. It also makes the code more lenient with errors during data collection: Only when no package name can be found do we return an error. Together with #10694 this will hopefully allow RPM package collection to work well.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Librpm installs its own signal handlers, preventing Beats from running its own Go handlers and causing an unclean shutdown. This summarily disables librpm's signal handlers. See #10633 (comment) for a detailed description of what is happening.
Resolves #10633.