[Auditbeat] Package: Open versioned librpm shared objects #11565
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
review
needs_backport
|
Pinging @elastic/secops |
adriansr
approved these changes
Apr 1, 2019
added 2 commits
April 1, 2019 21:17
cwurm
force-pushed
the
package_librpm_versions
branch
from
d593ad7 to
b7a8d4d
Compare
cwurm
pushed a commit
to cwurm/beats
that referenced
this pull request
Apr 1, 2019
) To access Librpm functions in the package dataset, we currently dlopen() `/usr/lib64/librpm.so` which is usually a symlink to the versioned shared object e.g. `/usr/lib64/librpm.so.1`. However, this symlink is only present when the package `rpm-devel` is installed and that's usually not the case by default. This PR changes to using the versioned shared object names as a fallback when the symlink is not available. Versions 1, 3, and 8 are library versions that are present on systems I've tested on, while other in-between versions are not explicitly tested, but it's reasonable to assume they work. In any case, if any of the functions we are looking for are not available the dataset will still abort. I've also changed from an absolute path (`/usr/lib64/librpm.so*`) to a generic one (`librpm.so*`) to be more flexible about the location. With this change, the package dataset works on CentOS 6, 7, and Fedora 29 without the `rpm-devel` package installed. The package is still required for compilation. (cherry picked from commit 5811355)
cwurm
added
v7.0.0
and removed
needs_backport
cwurm
pushed a commit
to cwurm/beats
that referenced
this pull request
Apr 1, 2019
) To access Librpm functions in the package dataset, we currently dlopen() `/usr/lib64/librpm.so` which is usually a symlink to the versioned shared object e.g. `/usr/lib64/librpm.so.1`. However, this symlink is only present when the package `rpm-devel` is installed and that's usually not the case by default. This PR changes to using the versioned shared object names as a fallback when the symlink is not available. Versions 1, 3, and 8 are library versions that are present on systems I've tested on, while other in-between versions are not explicitly tested, but it's reasonable to assume they work. In any case, if any of the functions we are looking for are not available the dataset will still abort. I've also changed from an absolute path (`/usr/lib64/librpm.so*`) to a generic one (`librpm.so*`) to be more flexible about the location. With this change, the package dataset works on CentOS 6, 7, and Fedora 29 without the `rpm-devel` package installed. The package is still required for compilation. (cherry picked from commit 5811355)
cwurm
pushed a commit
that referenced
this pull request
Apr 2, 2019
…11580) To access Librpm functions in the package dataset, we currently dlopen() `/usr/lib64/librpm.so` which is usually a symlink to the versioned shared object e.g. `/usr/lib64/librpm.so.1`. However, this symlink is only present when the package `rpm-devel` is installed and that's usually not the case by default. This PR changes to using the versioned shared object names as a fallback when the symlink is not available. Versions 1, 3, and 8 are library versions that are present on systems I've tested on, while other in-between versions are not explicitly tested, but it's reasonable to assume they work. In any case, if any of the functions we are looking for are not available the dataset will still abort. I've also changed from an absolute path (`/usr/lib64/librpm.so*`) to a generic one (`librpm.so*`) to be more flexible about the location. With this change, the package dataset works on CentOS 6, 7, and Fedora 29 without the `rpm-devel` package installed. The package is still required for compilation. (cherry picked from commit 5811355)
cwurm
pushed a commit
that referenced
this pull request
Apr 2, 2019
… shared objects (#11579) Cherry-pick of PR #11565 to 7.0 branch. Original message: To access Librpm functions in the package dataset, we currently dlopen() `/usr/lib64/librpm.so` which is usually a symlink to the versioned shared object e.g. `/usr/lib64/librpm.so.1`. However, this symlink is only present when the package `rpm-devel` is installed and that's usually not the case by default. This PR changes to using the versioned shared object names as a fallback when the symlink is not available. Versions 1, 3, and 8 are library versions that are present on systems I've tested on, while other in-between versions are not explicitly tested, but it's reasonable to assume they work. In any case, if any of the functions we are looking for are not available the dataset will still abort. We will have to add new versions as they become available, e.g. if Fedora 30 ships with `librpm.so.9` the dataset will not work out of the box until we add it to the search path. I've thought about adding it pre-emptively since it's likely that it will just work out of the box (we are not using that many functions, and none of the ones we use should have any side effects), but decided not to since we really don't know what could change. And since the generic `librpm.so` symlink is the first in the search path, it's always possible for the user to create or change this symlink to point to a version of their choice. I've also changed from an absolute path (`/usr/lib64/librpm.so*`) to a generic one (`librpm.so*`) to be more flexible about the location. With this change, the package dataset works on CentOS 6, 7, and Fedora 29 without the `rpm-devel` package installed. The package is still required for compilation.
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.
To access Librpm functions in the package dataset, we currently dlopen()
/usr/lib64/librpm.sowhich is usually a symlink to the versioned shared object e.g./usr/lib64/librpm.so.1. However, this symlink is only present when the packagerpm-develis installed and that's usually not the case by default.This PR changes to using the versioned shared object names as a fallback when the symlink is not available. Versions 1, 3, and 8 are library versions that are present on systems I've tested on, while other in-between versions are not explicitly tested, but it's reasonable to assume they work. In any case, if any of the functions we are looking for are not available the dataset will still abort.
We will have to add new versions as they become available, e.g. if Fedora 30 ships with
librpm.so.9the dataset will not work out of the box until we add it to the search path. I've thought about adding it pre-emptively since it's likely that it will just work out of the box (we are not using that many functions, and none of the ones we use should have any side effects), but decided not to since we really don't know what could change. And since the genericlibrpm.sosymlink is the first in the search path, it's always possible for the user to create or change this symlink to point to a version of their choice.I've also changed from an absolute path (
/usr/lib64/librpm.so*) to a generic one (librpm.so*) to be more flexible about the location.With this change, the package dataset works on CentOS 6, 7, and Fedora 29 without the
rpm-develpackage installed. The package is still required for compilation.