RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1439350 - glibc: [RFE][LLNL 7.5 FEAT] Create an option to permanently link in audit library into an executable (glibc)
Summary: glibc: [RFE][LLNL 7.5 FEAT] Create an option to permanently link in audit lib...
Keywords:
Status: CLOSED DUPLICATE of bug 1566146
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: glibc
Version: 8.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.0
Assignee: glibc team
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On: 1265827
Blocks: 1593423
TreeView+ depends on / blocked
 
Reported: 2017-04-05 18:57 UTC by Ben Woodard
Modified: 2023-07-18 14:30 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1439351 (view as bug list)
Environment:
Last Closed: 2019-08-28 10:08:24 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1439351 0 medium CLOSED [LLNL 7.5 FEAT] RFE create an option to permanently link in audit library into an executable (binutils) 2021-02-22 00:41:40 UTC

Internal Links: 1439351

Description Ben Woodard 2017-04-05 18:57:38 UTC
Description of problem:
At LLNL there are computational physicists who design interesting data sets that explore interest physics but who are not computer scientists. They run applications provided to them by computer scientists whose job is to implement the physics and make the binaries. The people who write and compile the programs are different than the people who generally run them.

The tools team at the lab generally would like to work the the computer scientists to provide tools that do various things. Several of their tools end up being implementable as audit libraries. One example is spindle http://computation.llnl.gov/projects/spindle another example is the common practice of wrapping library functions. In static cases wrapping can be done with LD_PRELOAD but to generalize the capability making it into an audit library that replaces the symbol and then calls the original is more effective.

In these cases the tools people want to work with the computer scientists and have them simply link in a tool library which is an audit library. An interface something like:

ld -faudit audit_lib.so foo.o bar.o -l libfoo.so ... -o exe

So that an original computer scientist can permanently have an audit lib loaded when the executable is run as if it were run like:

LD_AUDIT=audit_lib.so exe args...

ld.so would see the DT_NEEDED with some magic flag somewhere which says that this should be loaded as an audit library and dlmopened first and called the same way and the same times as if it were specified in the LD_AUDIT environment variable. This way it can replace the functions the way that spindle does or wrap the functions as needed.

This would require a new option to ld to specify the audit libraries to be linked in. That is more of a binutils feature. However, it would also require a change to ld.so which is part of glibc.

Additional info:

1) multiple audit libraries may be specified.
2) it is important that debuggers are able to debug code that is brought in through these audit libraries. Thus tools like GDB need to be able to find the link maps and enumerate the symbols in libraries which are brought in this way.

Comment 2 Carlos O'Donell 2017-04-19 22:56:11 UTC
Thanks for the RFE.

A Solaris design already exists for this.

https://docs.oracle.com/cd/E19120-01/open.solaris/819-0690/gfido/index.html

e.g. -Wl,-Paudit.so.1 -z globalaudit

Comment 3 Florian Weimer 2017-04-20 14:32:58 UTC
Suppose that a program uses this feature to install an audit module.  What should happen if the program is run with a glibc version which does not support this feature?

Should the program fail to start, or just run without loading the audit module?

Comment 4 Ben Woodard 2017-05-01 23:15:21 UTC
I am checking with the customer's tools team but I'm inclined to say that it it doesn't matter. Either way is fine. The use case almost precludes this from happening. So it is something highly hypothetical.

Comment 7 Carlos O'Donell 2019-06-07 19:24:27 UTC
The semantics of this solution are not yet pinned down for RHEL 7.8, and since RHEL 7 is entering Maintenance Phase 1 at the end of 2019 I'm going to move this bug to RHEL 8 where we can continue to use this to track requests from LLNL.

Comment 8 Florian Weimer 2019-08-28 10:08:24 UTC

*** This bug has been marked as a duplicate of bug 1566146 ***


Note You need to log in before you can comment on or make changes to this bug.