Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Auditbeat] Cherry-pick #11565 to 6.7: Package: Open versioned librpm shared objects #11580

Merged
merged 1 commit into from
Apr 2, 2019

Conversation

cwurm
Copy link
Contributor

@cwurm cwurm commented Apr 1, 2019

Cherry-pick of PR #11565 to 6.7 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.

)

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 cwurm changed the title Cherry-pick #11565 to 6.7: [Auditbeat] Package: Open versioned librpm shared objects [Auditbeat] Cherry-pick #11565 to 6.7: Package: Open versioned librpm shared objects Apr 1, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/secops

Copy link
Contributor

@tsg tsg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@cwurm cwurm merged commit b95beb8 into elastic:6.7 Apr 2, 2019
@cwurm cwurm deleted the backport_11565_6.7 branch April 2, 2019 11:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants