This is the only language-dependent nontrivial portion of the SWIG
bindings, and this should be good enough for anyone who is still using the
Perl bindings now
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
The message being optional is apparently a C23 thing that was available as an extension on the systems I tested on previously
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
The previous code using intmax_t failed to build on armhf because
intmax_t was long long int instead of long int on that platform.
As to shrinking down to a long: not only does SWIG lack a
SWIG_AsVal_intmax_t, but aalogparse also assumes PIDs fit in a long
by storing them as unsigned longs in aa_log_record. Thus, we can
assume that sizeof(pid_t) <= sizeof(long) right now and deal with
the big headache that a change to pid_t would cause if it becomes
larger than a long in the future.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
Unfortunately we are affected by the backwards-incompatible change introduced by https://github.com/swig/swig/pull/2907
These wrappers will be needed to fix tests on systems using SWIG 4.3 or later, e.g. Ubuntu Plucky.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
Changes to Python SWIG bindings that are breaking changes but that fix bindings that were previously unusable.
This MR also depends on !1334 and !1337 being merged first, though ~~I can rebase this one if necesssary~~ this MR has now been rebased after those two were merged.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1338
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: Georgia Garcia <georgia.garcia@canonical.com>
previously, this check would fail if the setuptools version would contain non-integers.
On my system, that is the case: `setuptools.__version__` is `'75.1.0.post0'`
I believe it is entirely fair to just check the relevant bits and refuse to continue if those can not be checked properly.
But haviong something extra on the version should not immediately cause issues (e.g. the `post0` here, or slugs like `beta`, `alpha` and the likes).
Probably only very few systems are running setuptools with weird version info, but supporting this doesn't cost much, i believe.
The prefix can be done in higher-level languages via slicing and having an explicit length exposes an out-of-bounds memory read footgun to those higher level languages
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
Surprisingly, SWIG did not pick up the "typedef int pid_t" from the C headers.
As such, we need to provide our own wrapper. We don't just replicate the typdef
because we still support systems that have 16-bit PIDs.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
In Python, return status is signalled by exceptions (or lack thereof)
instead of int. Keep the typemap portable for any other languages we may
add in the future.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
This includes a custom typemap to handle (char **label, char **mode)
pairs and a cstring_output_allocate declaration for char **mnt.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
This is one of those functions that never worked anyways, because it
modified the passed-in label in place. Moreover, it is a low-level
interface that requires its callers to manually construct a binary query.
As such, it would be better not to expose it and to add wrappers like
aa_query_file_path for the other query classes if that functionality is
needed later.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
It doesn't make sense to expose the *_raw functions or the varg version
of aa_change_hatv to higher-level languages. While technically a breaking
change, the generated bindings for these functions never actually worked
anyways:
- aa_change_hat_vargs uses C varargs, which SWIG passes in NULL for by
default. It does not attempt to process the passed-in arguments at all
(and in fact caused an unused-argument compiler warning when compiling
the generated bindings).
- aa_getprocattr_raw and aa_getpeercon_raw both place output into a char
**mode pointer. SWIG by default generates these as opaque pointer
object arguments, rendering them unusable for getting output. Future
patches would be needed to fix char** arguments for the other functions
that use them. Moreover, these functions expect their caller to handle
memory allocation, which is also not possible from a higher-level
language point of view.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
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>
Unfortunately SWIG_exception does not support throwing OSError, so this
still requires Python-specific code.
Unlike just returning NULL, this will clean up intermediate allocations.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
This change matches the names in the .c source and the man page for aa_query_label,
and also simplifies the typemap annotations needed to make the SWIG versions usable.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
The autoconf infrastructure for building this doesn't even show up in the Git history, so there should be no issue with removing the ghosts of Java from the codebase
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
Similarly to https://gitlab.com/apparmor/apparmor/-/merge_requests/689, use the
global CFLAGS when building Python library, so we honor extra flags set by
distributions, such
as -fstack-protector-strong -fstack-clash-protection -Werror=format-security -fcf-protection.
Spotted by blhc on Debian.
Gbp-Pq: Name Honor-global-CFLAGS-when-building-Python-library.patch
libraries/libapparmor/swig/python/test/buildpath.py:
The changes introduced in
cc7f549665
targetted a wrong setuptools version (61.2).
The change in build directory naming has been introduced with 62.1
(1c23f5e1e4).
The Hack used to build the libapparmor swig interface for ruby fails
with ruby 3.1. Instead of trying to do black magic in ruby to rename
the generated Makefile to Makefile.new, just save off the Makefile
and restore after ruby's setup has been called.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/206
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Christian Boltz <apparmor@cboltz.de>
