Re: What does LAV_CURRENT mean backwards compatibility of LD_AUDIT interface?

["Carlos O'Donell" <carlos 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.