On 11/13/19 3:30 AM, Nicolas Iooss wrote:
On Tue, Nov 12, 2019 at 4:39 PM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
On 11/11/19 6:53 AM, Nicolas Iooss wrote:
selinuxswig_python_exception.i and semanageswig_python_exception.i need
to be regenerated when either an input header file changes or
exception.sh changes. Add the missing items to the respective Makefiles.
Signed-off-by: Nicolas Iooss <nicolas.iooss@xxxxxxx>
Wondering if we ought to be passing the dependencies as arguments to
exception.sh and having it use them rather than a hardcoded header file
path, but regardless:
Acked-by: Stephen Smalley <sds@xxxxxxxxxxxxx>
I merged my three patches. Thanks for your review.
In my humble opinion, I find it simpler not to pass any argument to
the script, users can regenerate the files by running exception.sh
directly.
Nevertheless, when I wrote this patch, there is something that
surprised me. In libselinux, only functions in selinux.h are
considered when adding glue code to raise OSError from errno when a
function returns a negative value. Contrary to semanage.h, selinux.h
does not include every other libselinux headers. More precisely, "grep
'^extern int ' libselinux/include/selinux/*.h" shows some functions in
avc.h, label.h and restorecon.h that are not handled. For example
avc_netlink_open() documented in its manpage to return -1 and set
errno when an error occurs, but is not present in
selinuxswig_python_exception.i. Is this a bug?
If yes, fixing it requires changing the API of selinux Python module,
which could break some applications (a function would raise an
exception instead of returning -1).
Curiously selinuxswig.i #include's all (or at least many) of the selinux
headers in its %module selinux, whereas selinuxswig_python.i only
includes selinux.h as you note. I'm unclear on the history here. It
seems like a bug, but breaking API wouldn't be good either.
I also have doubts that it is a good idea to be exposing all of the
libselinux (or libsemanage) interfaces to python rather than a manually
curated list. But pruning that back now would also be difficult. We
could at least freeze the interface going forward and only add new
interfaces explicitly as needed/desired perhaps.
