Trying to support Python 3 but fails on libsemanage

Trying to support Python 3 but fails on libsemanage

[Sven Vermeulen]

I'm trying to get Python 3 support up and going with the SELinux userspace
utilities. I'm hitting a compatibility issue that I'm not able to work out
further.

This is the following "test case":
	semanage fcontext -a -t swapfile_t /swapfile
	semanage fcontext -d -t swapfile_t /swapfile

With Python 2.7, this works as it should be. With Python 3.2 however, I get
the following error while trying to delete the entry:

/usr/sbin/semanage: File context for /swapfile is not defined

The entry is correctly available in the file_contexts.local file. Also, if I
switch from Python 3.2 to 2.7 after adding the entry (but before removing),
removing the entry works as it should be.

I notice that semanage calls seobject.py which calls semanage.py. All these
files are exactly the same (no changes made to those), so I guess it is
something to do within the _semanage.so file.

Now, this is a library created through swig magic, which i'm totally unknown
to. It looks like all code is C-based, and then transformed into a
Python-compatible call, not?

Is there anyone already running the SELinux userspace tools with Python 3?
If so, how do you build libsemanage (as that provides the _semanage.so
file)?

Wkr,
	Sven Vermeulen


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Trying to support Python 3 but fails on libsemanage

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/16/2012 05:17 AM, Sven Vermeulen wrote:
> I'm trying to get Python 3 support up and going with the SELinux userspace 
> utilities. I'm hitting a compatibility issue that I'm not able to work out 
> further.
> 
> This is the following "test case": semanage fcontext -a -t swapfile_t
> /swapfile semanage fcontext -d -t swapfile_t /swapfile
> 
> With Python 2.7, this works as it should be. With Python 3.2 however, I
> get the following error while trying to delete the entry:
> 
> /usr/sbin/semanage: File context for /swapfile is not defined
> 
> The entry is correctly available in the file_contexts.local file. Also, if
> I switch from Python 3.2 to 2.7 after adding the entry (but before
> removing), removing the entry works as it should be.
> 
> I notice that semanage calls seobject.py which calls semanage.py. All
> these files are exactly the same (no changes made to those), so I guess it
> is something to do within the _semanage.so file.
> 
> Now, this is a library created through swig magic, which i'm totally
> unknown to. It looks like all code is C-based, and then transformed into a 
> Python-compatible call, not?
> 
> Is there anyone already running the SELinux userspace tools with Python 3? 
> If so, how do you build libsemanage (as that provides the _semanage.so 
> file)?
> 
> Wkr, Sven Vermeulen
> 
> 
> -- This message was distributed to subscribers of the selinux mailing
> list. If you no longer wish to subscribe, send mail to
> majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes
> as the message.

I have not tried to use python3 with semanage yet, did you actually port the
python py files to python3?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+1Jo8ACgkQrlYvE4MpobMRMwCg5sF7qgmNawO3lshoyI0IsBF3
X+YAn3QnXrfEdnyh9RKL96Qur4pUwcmI
=yaf9
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Trying to support Python 3 but fails on libsemanage

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On May 17, 2012 6:25 PM, "Daniel J Walsh" <dwalsh@redhat.com> wrote:
> I have not tried to use python3 with semanage yet, did you actually port
the
> python py files to python3?

Yes, and I think that went well (no more failures on print statements or
indentation mismatches), but now I'm quite stuck. I'm going to debug the
libselinux code a bit later (esp. the database handling as that's involved
in this use case) to try and learn about this ;-)

Wkr,
  Sven Vermeulen

[-- Attachment #2: Type: text/html, Size: 585 bytes --]

Re: Trying to support Python 3 but fails on libsemanage

[Sven Vermeulen]

On Wed, May 16, 2012 at 11:17:36AM +0200, Sven Vermeulen wrote:
> I'm trying to get Python 3 support up and going with the SELinux userspace
> utilities. I'm hitting a compatibility issue that I'm not able to work out
> further.
> 
> This is the following "test case":
> 	semanage fcontext -a -t swapfile_t /swapfile
> 	semanage fcontext -d -t swapfile_t /swapfile
> 
> With Python 2.7, this works as it should be. With Python 3.2 however, I get
> the following error while trying to delete the entry:
> 
> /usr/sbin/semanage: File context for /swapfile is not defined

I've not been able to debug this much further, but this is as far as I got
today...

(1.) semanage (the python script) calls the python seobject class, more
     specifically the seobject.fcontextRecords class
(2.) in seobject.fcontextRecords, deleting a file context goes to the
     __delete function
(3.) in __delete, semanage_fcontext_key_create(self.sh, target,
     file_type[fstype]) is called, which returns rc (return code) and k (the
     key used to interact with libsemanage)

     self.sh is a handle used to keep track of the "transaction", target is
     the string of the file context to delete (like "/swapfile"),
     file_type[fstype] here is for specific types of contexts

(4.) semanage_fcontext_key_create() goes to the _semanage.so shared library
     (through semanage.py which imports _semanage), which is created from the
     libsemanage code through swig

(5.) The semanage_fcontext_key_create() function is defined in
     src/fcontext_record.c. It allocates memory, puts in the information
     (like expression = "/swapfile") and returns the address of this memory
     location as key

So far I can follow how things go. Since the Python script uses the
_semanage.so as library, it can (or should) use the memory address without
problems (no forks or so involved, so the memory address should remain
correct, right?)

However, what happens next is a bit too unclear to me. 

(6.) In seobject.py, the function "semanage_fcontext_exists_local" is
     called. The name obviously tells me we're going to see if the file
     definition is mentioned in the file_contexts.local so that it can be
     removed. It uses the key as a reference to seek this information.
(7.) semanage_fcontext_exists_local is defined in src/fcontexts_local.c, but
     this contains the following:

        dbase_config_t *dconfig = semanage_fcontext_dbase_local(handle);
        return dbase_exists(handle, dconfig, key, response);

     What is semanage_fcontext_dbase_local(handle)'s job? Is this to define
     the target database to work with (in our case, for file contexts)?
(8.) dbase_exists() is defined in src/databqse.c. It calls the following:

        dconfig->dtable->exists(handle, dconfig->dbase, key, response)

     I assume the function "exists" depends on the dtable, which comes from
     dconfig, and which - in our case - will refer to
     semanage_fcontext_compare (in src/fcontext_record.c)

Now here's where the fun part comes in.

In both semanage_fcontext_key_create() and semanage_fcontext_compare() I
have added some debugging statements, namely:

fprintf(stderr, "DEBUG - create: key is %u, expr is \"%s\"\n", key, key->expr);
and
fprintf(stderr, "DEBUG - compare: key is %u, expr is \"%s\"\n", key, key->expr);


When I run the mentioned use case with Python 2.7, I get the following
(expected) output:

DEBUG - create: key is 3216874400, expr is "/swapfile"
DEBUG - compare: key is 3216874400, expr is "/swapfile"
DEBUG - compare: key is 3216874400, expr is "/swapfile"

after which it gets deleted (the two compare-debug lines are because the
file_contexts.local has two entries, and the second one matches).

With Python 3.2, it becomes the following:

DEBUG - create: key is 973543696, expr is "/swapfile"
DEBUG - compare: key is 973543696, expr is ""�0^\"
DEBUG - compare: key is 973543696, expr is ""�0^\"
...


Somewhere between creating the key and checking its content, the content of
the memory is changed (or the target of the pointer pointing to the
expression). Since the key itself (address) is unchanged, this is done
somewhere in the libsemanage code, right?

But if it is, and the code doesn't seem to have any #if PY_MAJOR_VERSION ...  #endif
constructs in it, what can then cause Python 2.7 to behave differently here?
Is it the swig'ed result that differs from Python 2.7 and Python 3.2? If so,
is there any way this can be debugged easily?

Wkr,
	Sven Vermeulen

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Trying to support Python 3 but fails on libsemanage

[Sven Vermeulen]

On Wed, May 23, 2012 at 10:35:19PM +0200, Sven Vermeulen wrote:
> > This is the following "test case":
> > 	semanage fcontext -a -t swapfile_t /swapfile
> > 	semanage fcontext -d -t swapfile_t /swapfile
> > 
> > With Python 2.7, this works as it should be. With Python 3.2 however, I get
> > the following error while trying to delete the entry:
> > 
> > /usr/sbin/semanage: File context for /swapfile is not defined
> 
[...]
> (5.) The semanage_fcontext_key_create() function is defined in
>      src/fcontext_record.c. It allocates memory, puts in the information
>      (like expression = "/swapfile") and returns the address of this memory
>      location as key
[...]
> Somewhere between creating the key and checking its content, the content of
> the memory is changed (or the target of the pointer pointing to the
> expression). Since the key itself (address) is unchanged, this is done
> somewhere in the libsemanage code, right?
> 
> But if it is, and the code doesn't seem to have any #if PY_MAJOR_VERSION ...  #endif
> constructs in it, what can then cause Python 2.7 to behave differently here?
> Is it the swig'ed result that differs from Python 2.7 and Python 3.2? If so,
> is there any way this can be debugged easily?

David Malcolm gave me a good hint at what to look for.

The key that is created contains a link towards a regular expression (in the
above use case, that expression would be "/swapfile") which is passed on
from the Python code towards the shared library (through
semanage_fcontext_key_create). I think that, in Python 2.7, the memory
allocation for this expression is either not freed at the same time as with
Python 3.2, or it is freed but not reused (in which case the stale
information is still there).

If I apply the following patch to libsemanage, the use case works for both
Python 2.7 and Python 3.2.

Wkr,
	Sven Vermeulen

diff -ur libsemanage-2.1.6.orig/src/fcontext_record.c libsemanage-2.1.6/src/fcontext_record.c
--- libsemanage-2.1.6.orig/src/fcontext_record.c	2012-05-22 21:50:23.416071391 +0200
+++ libsemanage-2.1.6/src/fcontext_record.c	2012-05-26 09:08:22.125114161 +0200
@@ -45,7 +45,11 @@
 		    "create file context key");
 		return STATUS_ERR;
 	}
-	tmp_key->expr = expr;
+	tmp_key->expr = strdup(expr);
+	if (!tmp_key->expr) {
+		ERR(handle, "out of memory, could not create file context key.");
+		return STATUS_ERR;
+	}
 	tmp_key->type = type;
 
 	*key_ptr = tmp_key;
@@ -74,6 +79,7 @@
 
 void semanage_fcontext_key_free(semanage_fcontext_key_t * key)
 {
+	free(key->expr);
 	free(key);
 }


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Trying to support Python 3 but fails on libsemanage

[Eric Paris]

On Sat, May 26, 2012 at 12:44 PM, Sven Vermeulen
<sven.vermeulen@siphos.be> wrote:
> On Wed, May 23, 2012 at 10:35:19PM +0200, Sven Vermeulen wrote:
> diff -ur libsemanage-2.1.6.orig/src/fcontext_record.c libsemanage-2.1.6/src/fcontext_record.c
> --- libsemanage-2.1.6.orig/src/fcontext_record.c        2012-05-22 21:50:23.416071391 +0200
> +++ libsemanage-2.1.6/src/fcontext_record.c     2012-05-26 09:08:22.125114161 +0200
> @@ -45,7 +45,11 @@
>                    "create file context key");
>                return STATUS_ERR;
>        }
> -       tmp_key->expr = expr;
> +       tmp_key->expr = strdup(expr);
> +       if (!tmp_key->expr) {
> +               ERR(handle, "out of memory, could not create file context key.");
> +               return STATUS_ERR;
> +       }
>        tmp_key->type = type;
>
>        *key_ptr = tmp_key;
> @@ -74,6 +79,7 @@
>
>  void semanage_fcontext_key_free(semanage_fcontext_key_t * key)
>  {
> +       free(key->expr);
>        free(key);
>  }

key->expr is a const char * so free() is not 'allowed'.  I changed it
to just a char * (which is what strdup returns) so the code could
build.  Thanks!

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.