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

[Steve Beattie]

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?

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
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.

> 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).

Thanks.

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20131010/0fb39e3e/attachment.pgp>