Bug 908916

Summary: python bindings traceback with cryptic error when unicode type is given
Product: [Fedora] Fedora Reporter: Toshio Ernie Kuratomi <a.badger>
Component: libselinuxAssignee: Daniel Walsh <dwalsh>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: dmalcolm, dwalsh, kevin, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-14 13:04:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
Patch to fix the python functions for unicode strings
none
Second try at patch to fix the python functions for unicode strings none

Description Toshio Ernie Kuratomi 2013-02-07 20:47:53 UTC
Created attachment 694748 [details]
Patch to fix the python functions for unicode strings

Description of problem:

We have some code that's creating a directory and then trying to set proper selinux attributes on it.  We use something like this:

import selinux
selinux.copytree('/etc/skel', homedir)

This makes the following traceback:

Traceback (most recent call last):
  File "/usr/bin/fasClient", line 789, in <module>
    fas.create_home_dirs(users, modes=modes)
  File "/usr/bin/fasClient", line 548, in create_home_dirs
    copytree('/etc/skel/', home_dir)
  File "/usr/lib/python2.6/site-packages/selinux/__init__.py", line 100, in copytree
    restorecon(dest, recursive=True)
  File "/usr/lib/python2.6/site-packages/selinux/__init__.py", line 76, in restorecon
    status, context = matchpathcon(path, mode)
TypeError: in method 'matchpathcon', argument 1 of type 'char const *'
the swig bindings to 

After some debugging I figured out that  our homedir variable contains something like this: u'/home/newuser'.  This is a python unicode string type rather than a python str (byte string) type.  The swig bindings are unable to handle these unicode strings.  Only byte str.

I have a patch that fixes this for the functions in the swig interface definition that are written in python by converting the strings from unicode to str using the user's current locale (this is what is done by the shutils module which is currently being used in several places in the selinux python bindings).  Not sure how to fix it in the ones that are direct reflections of the C api generated by swig.

An alternative to this strategy would be to have the python bindings give a better error message if they encounter a unicode string.  For the python code, that would look something like this:

def copytree(src, dest):
    if not isinstance(src, str):
        raise TypeError('src must be a byte str')
    if not isinstance(dest, str):
        raise TypeError('dest must be a byte str')
    shutil.copytree(src, dest)
    restorecon(dest, recursive=True)

Once again, I'm not sure how to achieve that same effect in the swig-generated bindings to the C API.

Version-Release number of selected component (if applicable):
libselinux-2.1.13-1.fc19

How reproducible:

Everytime

Steps to Reproduce:
1. sudo python
2. import selinux
3. selinux.copytree('/etc/skel', '/home/test')
  
Actual results:

Traceback shown above

Expected results:

Copy the directory and its contents.  Then give it the appropriate selinux labels.

Additional info:

Comment 1 Daniel Walsh 2013-02-08 20:04:06 UTC
I can not read your patch.

Comment 2 Toshio Ernie Kuratomi 2013-02-08 21:25:52 UTC
Created attachment 695237 [details]
Second try at patch to fix the python functions for unicode strings

Sorry about that -- looks like I managed to upload the rpm instead of the patch.  Try this version.

Comment 3 Daniel Walsh 2013-02-12 19:24:04 UTC
Dave what do you think?

Comment 4 Fedora End Of Life 2013-04-03 14:43:58 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 5 Fedora End Of Life 2015-01-09 17:39:27 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.