[apparmor] [RFC] [patch] Makefile automatically fallback to USE_SYSTEM=1

[John Johansen]

On 03/11/2014 03:51 PM, Steve Beattie wrote:
> On Tue, Mar 11, 2014 at 12:22:19PM -0700, John Johansen wrote:
>> On 03/11/2014 11:52 AM, Steve Beattie wrote:
>>> I'm still mulling/trying to remember the arguments from when we added
>>> USE_SYSTEM so I don't have a yay or nay on this patch.
>>
>> I don't remember it either, but I am finding the current behavior a
>> major annoyance. This or something like it doesn't have to make it
>> upstream but I will continue to use it, which is why the RFC.
> 
> Alright, I've refreshed my memory. Initially, I had implemented
> the behavior you wanted, except that I did it poorly because the
> in-tree apparmor.h header would always be found and used; however,
> if the library wasn't built, then the system one would be used. It
> was rightly pointed out that having a mismatch of header to library
> was setting up someone for a bad failure.
> 
yeah

> Others have argued that the fallback behavior is dangerous even if
> implemented correctly. I'm not entirely convinced of that, but I
I can see that argument, I obviously disagree but ...

> will continue to strenuously argue that using the in-tree library
> is the safer and preferred option, and depending on the age of the
> libapparmor on the platform you're building on, you may suffer from
> compilation failures (for example, trunk parser fails to compile
> against the libapparmor provided by Ubuntu 13.10).
> 
yes

> On Tue, Mar 11, 2014 at 12:27:27PM -0700, John Johansen wrote:
>> On 03/09/2014 09:36 AM, Christian Boltz wrote:
>>> I understand why you like this behaviour, but I don't like it too much 
>>> because it introduces some "surprising" behaviour. (And I doubt someone 
>>> reads the warning if the test succeeds ;-)
>>>
>> I'm not sure why its a surprising behavior, but okay. Question is who
>> do you see the consumer as?
> 
> We have multiple consumers: developers (like you and me), distribution
> packagers (who may or may not be following bikeshedding discussions
> about build behavior and build ordering), and end users (who
> have similar issues as distributors, though granted an end user is
> typically pulling our tarball because their platform doesn't provide
> apparmor, so there's no system libapparmor to build against to
well that or they want to upgrade one part of apparmor, and their
distribution hasn't upgraded it yet. There are all kinds of reasons
to want a new parser or tools without having a new lib.

> begin with).  It's definitely not out of the realm of possibilities
> for a distribution packager to not build stuff in the right order
> (i.e. not build libapparmor first), such that some things get built
> with the system libapparmor.
> 
true enough

>>> Thinking about it - can you implement an additional condition like 
>>> "file common/enable-auto-fallback-to-USE_SYSTEM exists" (or an 
>>> environment variable you set in .bashrc, but a file sounds better)?
>>>
>>> That would mean people have to actively opt-in to the automatical 
>>> fallback by touch'ing the file once in their bzr checkout. This would 
>>> fix the "surprise" part.
>>>
>>> With the opt-in file added, the patch looks good to me.
>>>
>> using a file is possible, but how about opt-out instead? It would be
>> easy to add USE_SYSTEM=0, to opt-out. So if USE_SYSTEM is defined
>> (either 0 or 1) you get one or the other behavior other wise it tries
>> to build against one then the other
> 
> Are you intending this behavior for just the regression tests or for
> everywhere in the tree that libapparmor is made use of?
> 
That really was part of the question, but I wanted the discussion before
I put any effort into fixing it else where. I very much want it for the
parser and kernel regression tests.

> I'm okay with this approach (particularly since I already tried to
> implement fallback behavior once poorly), so long as a warning is
> given if falling back. And if your intended scope is across the tree,
> that we encourage distros to build with USE_SYSTEM=0 in addition to
> the VERBOSE=1 we already recommend.
> 
yes

> In any event, all of this serves as a reminder to be careful with
> the libapparmor ABI/API.
> 
Right test wise we are going to want to come up with some more
smarts so that the build system can drop certain tests when it
hits old libraries etc.

For me this is very necessary because we get all kinds of combinations
between kernels and userspaces, and we need to be testing for these
making sure the new kernels work with old userspaces etc.