[apparmor] [patch 01/13] parser - build against in-tree libapparmor

[John Johansen]

On 10/10/2013 06:25 PM, Steve Beattie wrote:
> On Thu, Oct 10, 2013 at 03:33:19PM -0700, John Johansen wrote:
>> On 10/10/2013 01:46 PM, Steve Beattie wrote:
>>> With trunk commit 2205 "use libapparmor's find mountpoint fn",
>>> the parser now builds against and uses libapparmor at runtime. However,
>>> it currently builds against the system installed libapparmor library and
>>> header files, which fails if either aren't installed, and is thus
>>> painful for bootstrapping in a new environment.
>>>
>>> Instead, the parser, like pam_apparmor and mod_apparmor, should build
>>> against the in-tree libapparmor header and library. This patch does
>>> that and adjusts the tests to point LD_LIBRARY_PATH at the location
>>> of the built library as well.
>>>
>>> Signed-off-by: Steve Beattie <steve at nxnw.org>
>>
>> NAK
>>
>> at least in the current form, this really breaks me. The idea is good
>> but for dev purposes I am often building the parser where I have a
>> library that won't build.
> 
> Do you commonly break the apparmor.h header in libapparmor?

uhhm yes it can sit broken or wrong for weeks/months. I tend to keep
multiple patches staged and push/pop pull up and down the stack.

I probably should create new branches but, it is a real pain. /me
doesn't like working in bzr and creating new branches that way, and
branches are problematic in git when using git-bzr-ng

> 
> So, I didn't really want to point this out, but all the patch is doing
> is adding to the include and library search paths. For the include of
> apparmor.h, at build time, with this patch, it won't find the system
> one because /usr/include/sys is not on the default search path. Thus,
> if you do something that breaks the header, you'll break your compile.
> 
> However, for the library, I don't specifically link in the in-tree
> library, I just add the location it gets built in to the library
> search path for linking. Note that the system library paths are still
err which brings up the other point, don't we need to be linking in
the library statically so that parser can load in early boot before
/usr is available.

> included, and so if you have it available, it will still fall back to
> linking against it. Even the tests, by specifying LD_LIBRARY_PATH,
> will search the in-tree location first, and then fall back to the
> system locations if the in-tree version is not found. So, unless
> you're specifically breaking things in the header file, you should
> still be okay with the system libapparmor devel bits installed.
> 
> That said, depending on how old your system libapparmor is, you may
> still have symbol mismatches. But you can run into that situation now,
> and this patch improves it for the situation where people build the
> library first or don't have it at all.
> 
> Now, all that said, I was eventually going to come around to the
> regression tests and having them build against the tree libapparmor and
> use the in-tree parser for testing by default. However, I still want
> to to retain the ability to run all of our non-unit tests against
> system binaries, and so had envisioned for the regression tests
> some sort of alternate make target or build variable ('USE_SYSTEM'
> ?) to indicate compiling against the system libapparmor and using the
> system parser. I would consider doing something here in the parser
> source as well, if you still feel that it's necessary.
> 
yep, sorry

>> can we modifiy the LIBAPPARMOR_PATH with conditional assign or something
>> so I can a least do
>>
>>   make LIBAPPARMOR_PATH=blah
> 
> The patch is not currently set up in the most usable way (because
> the linking path for libapparmor.so is not a separate variable) but
> gnu make variables are overrideable like so by default. For example:
> 
>   make AARE_LDFLAGS="-static-libgcc -L. -L/usr/lib/"
> 
> causes the parser to link successfully against the system
> libapparmor.so just as you want. I can definitely add a similar
> LIBAPPARMOR_LDPATH variable. I'm not sure it's warranted, however,
> unless you have situations where you need to link against a
> libapparmor.so that's neither the in-tree version nor the system
> version (a development possibility I can kind of see).
> 
or if the in tree one is broken, like I sadly often have