This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: What does LAV_CURRENT mean backwards compatibility of LD_AUDIT interface?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Ben Woodard <woodard at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Matt Legendre <legendre1 at llnl dot gov>
- Date: Thu, 26 Feb 2015 23:12:44 -0500
- Subject: Re: What does LAV_CURRENT mean backwards compatibility of LD_AUDIT interface?
- Authentication-results: sourceware.org; auth=none
- References: <54EFBC96 dot 7010608 at redhat dot com> <D662FD8B-23A9-48B9-8CB0-AA6B7C976627 at redhat dot com>
On 02/26/2015 08:10 PM, Ben Woodard wrote:
>
>> On Feb 26, 2015, at 4:38 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> At present glibc defines LAV_CURRENT as 1.
>>
>> Should we wish to add new features to LD_AUDIT, what do we
>> do with this number and what does it mean?
>
> I think that the man page makes this pretty clear when it says:
The man page is not canonical documentation for the project.
However, it does impact the way the audit libraries have been written
since the manual pages are presently the *only* documentation.
> As its function result, this function should return the version of
> the auditing interface that this auditing library expects to use
> (returning version is acceptable). If the returned value is 0, or a
> version that is greater than that supported by the dynamic linker,
> then the audit library is ignored.
That statement says only:
- If la_version returns 0 the module is not loaded.
- If you request a version the present loader can't possibly implement
then the module is not loaded.
It says nothing about the inter-version behaviour.
The inter-version compatibility still has to be decided.
> So I believe that this documentation indicates that N+1 was intended
> to backward compatible. An audit library written for an old version
> of the audit interface simply returns the version of the audit
> interface that it was designed to use. In the case of sotruss-lib.c
> the code could be:
>
> /* Audit interface verification. We also initialize everything if
> everything checks out OK. */
> unsigned int
> la_version (unsigned int v)
> {
> if (v >LAV_CURRENT){
> warn (1, 0, ârecompile for newer audit interface version %u", v);
> }
Why a warning? The only thing of interest is in raising an error if
the features you need are not supported by the dynamic loader.
if (v < LAV_CURRENT)
{
... Raise error if loading the audit library is required.
}
> If we introduce an interface that is not backward compatible (highly
> unlikely), then when an audit library's la_version() returns a lower
> incompatible version number we can either:
> a) emulate the older versionâs behavior
> b) give the user some sort of error saying that version is not supported.
Yes, a) is what I discussed along with versioning to allow a shared
library to implement support for multiple different dyanmic loaders
across distributions.
An error is not a good idea since it would be unexpected, but a
diagnostic output in LD_DEBUG mode would be useful.
Cheers,
Carlos.