[apparmor] [patch] libapparmor: aa_query_label symbol versioning

John Johansen john.johansen at canonical.com
Sat Mar 1 20:14:40 UTC 2014


On 03/01/2014 09:25 AM, Steve Beattie wrote:
> On Sat, Mar 01, 2014 at 04:41:51AM -0800, John Johansen wrote:
>> On 02/28/2014 01:46 PM, Steve Beattie wrote:
>>> A slightly more invasive but conservative solution is to provide both
>>> versions (APPARMOR_1.1 and APPARMOR_3.0) of the aa_query_label()
>>> symbol. It requires the function name in kernel_interface.c to
>>> be renamed (similar to how the deprecated change_hat() symbol is
>>> named in the source as __change_hat()), otherwise linking fails
>>> with duplicated symbols. The default symbol used will still be the
>>> APPARMOR_3.0 version, but binaries linked with the APPARMOR_1.1 version
>>> would still continue to work unchanged. Keeping the (misleading)
>>> APPARMOR_3.0 version would prevent breaking anyone currently using
>>> a snapshot of trunk. This is the second patch attached.
>>>
>> So in general I like this, I question keeping the symbol version at
>> APPARMOR_3.0, as we your other patch added a place holder 2.9
>> which would seem to be the right place for it
>>
>> Also does the aa_query_label for the both versions have to be
>> present in the map? The patch only adds it for 1.1
> 
> Yes, it needs to be in both sections. The second patch adds it only
> for APPARMOR_1.1, because it's already in the map file under the
> APPARMOR_3.0 section.
> 
> I'm on the fence about changing the symbol to APPARMOR_2.9: on
> the one hand I'd prefer it because it more accurately reflects the
> release that will introduce the new symbol; on the other, the risk
> of breaking someone who's been using a snapshot of trunk -- though,
> it must be said that they would only break if they were using the
> aa_query_label symbol, which isn't likely, since it's the patch to
> dbus that is the sole consumer that I'm aware of. So changing to
> APPARMOR_2.9 is almost assuredly safe.
>

yeah, I think we are safe. Lets do it




More information about the AppArmor mailing list