Swig generates a "thisown" attribute, which is an escape hatch in case
higher-level code does something weird and needs to tell SWIG whether to
free the C object when Python garbage collects it. Adding this attribute
is not a breaking change w.r.t access to the other attributes of the parsed
record.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
When building with swig 4 we are seeing the error
AttributeError: 'aa_log_record' object has no attribute '__getattr__'
Which forces swig to use modern classes which do not generate __getattr__
methods.
issue: https://gitlab.com/apparmor/apparmor/issues/33
Acked-by: Seth Arnold <seth.arnold@canonical.com>
Acked-by: Steve Beattie <steve@nxnw.org>
Signed-off-by: John Johansen <john.johansen@canonical.com>
The added testcase for a ptrace target with an empty string
(ptrace_garbage_lp1689667_1.in) was causing the swig python test script
to fail. The generated python swig record for libapparmor ends up
setting a number of fields to None or other values that indicate the
value is unset, and the test script was checking if the value in the
field didn't evaluate to False in a python 'if' test.
Unfortunately, python evaluates the empty string '' as False in 'if'
tests, resulting in the specific field that contained the empty string
to be dropped from the returned record. This commit fixes that by
special case checking for the empty string.
Signed-off-by: Steve Beattie <steve@nxnw.org>
Acked-by: John Johansen <john.johansen@canonical.com>
The python bindings were using the wrong data type cast (long long
instead of just long) on the value '-1' that is used to indicate no
value for the 'fsuid' and 'ouid' fields in the returned data structure.
Thus a bunch of the tests were failing in 32bit environments.
This patch corrects the issue.
Signed-off-by: Steve Beattie <steve@nxnw.org>
Acked-by: Seth Arnold <seth.arnold@canonical.com>
This patch adds tests for the swig generated python library bindings
that reuse the C language tests.
Fitting it into autotools was a bit of a trick, and is likely pretty
brittle, as before the test script runs, it needs to know the location
of the built libapparmor.so library, the built _LibAppArmor.so library
and the python wrapper bits (thankfully, the latter two are the same
directory). It's also unclear how to get autotools to emit the output of
the test_python.py script when building, rather than just summarizing it
as one test run.
Also note that test_python.py is doing a bit of magic to automatically
generate test case methods based on the contents of the test_multi/
directory. This has the disadvantage of breaking tools like nosetests
and other external tools that try to automatically detect testcases.
Signed-off-by: Steve Beattie <steve@nxnw.org>
Acked-by: Tyler Hicks <tyhicks@canonical.com>
