(In reply to comment #0)
> Description of problem:
> 
> Regression from Fedora 8.
> With new Fedora 12 release, python curses module is compiled against
> libncurses.so again instead of libncursesw.so, so UTF-8 strings are not
> properly displayed.
> 
> $ ldd  ldd /usr/lib64/python2.6/lib-dynload/_curses*
> /usr/lib64/python2.6/lib-dynload/_cursesmodule.so:
>  linux-vdso.so.1 =>  (0x00007fff41bff000)
>  libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f62300b0000)
>  libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f622fe8f000)
>  libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f622fc72000)
>  libc.so.6 => /lib64/libc.so.6 (0x00007f622f8fa000)
>  libdl.so.2 => /lib64/libdl.so.2 (0x00007f622f6f6000)
>  /lib64/ld-linux-x86-64.so.2 (0x0000003b74800000)
> /usr/lib64/python2.6/lib-dynload/_curses_panel.so:
>  linux-vdso.so.1 =>  (0x00007fffe5d72000)
>  libpanel.so.5 => /usr/lib64/libpanel.so.5 (0x00007fe41373b000)
>  libncurses.so.5 => /lib64/libncurses.so.5 (0x00007fe413519000)
>  libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe4132fc000)
>  libc.so.6 => /lib64/libc.so.6 (0x00007fe412f84000)
>  libdl.so.2 => /lib64/libdl.so.2 (0x00007fe412d80000)
>  libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007fe412b5e000)
>  /lib64/ld-linux-x86-64.so.2 (0x0000003b74800000)
> 
> Please, recompile against libncursesw.so
> 
> This bug is related to old bugs #242583, #250782 and maybe others.  

#246385 was the original bug about this issue.

Note to self: the (closed) upstream issue "Prefer linking against ncursesw over ncurses library" mentioned in bug 242583 is now here:
http://bugs.python.org/issue1428494

Our downstream patch to Modules/Setup.dist (python-2.6.2-config.patch) enables cursemodule to be built directly via the main Makefile written by "configure", but uses "-lcurses" rather than "-lncursesw" for linking both "_curses" and "_curses_panel".

This happens before the tests in setup.py (the ./python executable hasn't even been linked at this point), so the logic to fix this mentioned in http://bugs.python.org/issue1428494 isn't run: the module has already been compiled and linked, using the (incorrect) linker flags given in our patch.

Jack Miller and Mark Knoop worked on this (see bug 541386) and Mark has provided a patch for this (attachment 384817 [details] to bug 541386), which (if I'm reading it correctly) removes the modules from the Setup.dist, so that they are instead handled by the setup.py code, thus preferring the "w" implementations.

It looks like there's a "w" implementation of libpanel; do we need to ensure that we link against the libpanelw rather than libpanel?


It looks like this issue also affects our python3 rpms; analogous changes are present in the python-3.1.1-config.patch in the python3 SRPM.

On my machine (though this is with local rebuilds of both python and python3, without fixing these patches):
$ ldd /usr/lib*/python*/lib-dynload/_curses*|grep curses
/usr/lib/python2.6/lib-dynload/_cursesmodule.so:
	libncurses.so.5 => /lib/libncurses.so.5 (0x003f1000)
/usr/lib/python2.6/lib-dynload/_curses_panel.so:
	libncurses.so.5 => /lib/libncurses.so.5 (0x008c6000)
/usr/lib/python3.1/lib-dynload/_cursesmodule.so:
	libncurses.so.5 => /lib/libncurses.so.5 (0x00c45000)
/usr/lib/python3.1/lib-dynload/_curses_panel.so:
	libncurses.so.5 => /lib/libncurses.so.5 (0x00110000)

$ ldd /usr/lib*/python*/lib-dynload/_curses*|grep panel
/usr/lib/python2.6/lib-dynload/_curses_panel.so:
	libpanel.so.5 => /usr/lib/libpanel.so.5 (0x00975000)
/usr/lib/python3.1/lib-dynload/_curses_panel.so:
	libpanel.so.5 => /usr/lib/libpanel.so.5 (0x006e4000)

For reference:
$ ll /lib/libncurses*
lrwxrwxrwx. 1 root root     17 2009-12-01 18:48 /lib/libncurses.so.5 -> libncurses.so.5.7
-rwxr-xr-x. 1 root root 141780 2009-07-27 00:34 /lib/libncurses.so.5.7
lrwxrwxrwx. 1 root root     18 2009-12-01 18:48 /lib/libncursesw.so.5 -> libncursesw.so.5.7
-rwxr-xr-x. 1 root root 196824 2009-07-27 00:34 /lib/libncursesw.so.5.7

$ rpm -qf /lib/libncurses* | sort | uniq
ncurses-libs-5.7-3.20090207.fc12.i686

$ ll /usr/lib/libncurses*
lrwxrwxrwx. 1 root root 25 2009-12-01 18:56 /usr/lib/libncurses.so -> ../../lib/libncurses.so.5
lrwxrwxrwx. 1 root root 26 2009-12-01 18:56 /usr/lib/libncursesw.so -> ../../lib/libncursesw.so.5

$ rpm -qf /usr/lib/libncurses* | sort | uniq
ncurses-devel-5.7-3.20090207.fc12.i686

(In reply to comment #3)
> It looks like there's a "w" implementation of libpanel; do we need to ensure
> that we link against the libpanelw rather than libpanel?

Probably a wise idea.

F-12 changelog:
* Mon Jan 25 2010 David Malcolm <dmalcolm> - 2.6.2-4
- change python-2.6.2-config.patch to remove our downstream change to curses
configuration in Modules/Setup.dist, so that the curses modules are built using
setup.py with the downstream default (linking against libncursesw.so, rather
than libncurses.so), rather than within the Makefile; add a test to %%install
to verify the dso files that the curses module is linked against the correct
DSO (bug 539917; changes _cursesmodule.so -> _curses.so)

Fix tested with scratch builds; applied in dist-cvs; tested on F-12 with a local build (canto works).

Rebuilding in Koji now for the various branches:
F-12 python 2: python-2.6.2-4.fc12   http://koji.fedoraproject.org/koji/taskinfo?taskID=1943752
F-13 python 3: python-2.6.4-9.fc13   http://koji.fedoraproject.org/koji/taskinfo?taskID=1943756
F-13 python 3: python3-3.1.1-20.fc13 http://koji.fedoraproject.org/koji/taskinfo?taskID=1943766

(In reply to comment #5)
> 
> F-13 python 3: python-2.6.4-9.fc13  
should have read "F-13 python 2: python-2.6.4-9.fc13"

(In reply to comment #5)

This correctly fixes the issue, at least with python 2 on fedora 12.

python-2.6.2-4.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update python'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0393

(In reply to comment #8)
> python-2.6.2-4.fc12 has been pushed to the Fedora 12 testing repository.  If
> problems still persist, please make note of it in this bug report.
>  If you want to test the update, you can install it with 
>  su -c 'yum --enablerepo=updates-testing update python'.  You can provide
> feedback for this update here:
> http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0393    

Works ok.

OK, I've installed this from updates-testing, and am now getting this SELinux
alert. Never seen it before, but the python update coincided with an
selinux-policy update... so I'm not sure which one to blame!


Summary:

SELinux is preventing /usr/libexec/abrt-hook-python "getattr" access on /.

Detailed Description:

[abrt-hook-pytho has a permissive type (abrt_helper_t). This access was not
denied.]

SELinux denied access requested by abrt-hook-pytho. It is not expected that this
access is required by abrt-hook-pytho and this access may signal an intrusion
attempt. It is also possible that the specific version or configuration of the
application is causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
report.

Additional Information:

Source Context                unconfined_u:unconfined_r:abrt_helper_t:s0-s0:c0.c
                              1023
Target Context                system_u:object_r:fs_t:s0
Target Objects                / [ filesystem ]
Source                        abrt-hook-pytho
Source Path                   /usr/libexec/abrt-hook-python
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           abrt-addon-python-1.0.4-1.fc12
Target RPM Packages           filesystem-2.4.30-2.fc12
Policy RPM                    selinux-policy-3.6.32-73.fc12
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 2.6.31.12-174.2.3.fc12.x86_64
                              #1 SMP Mon Jan 18 19:52:07 UTC 2010 x86_64 x86_64
Alert Count                   1
First Seen                    Fri 29 Jan 2010 16:21:16 GMT
Last Seen                     Fri 29 Jan 2010 16:21:16 GMT
Local ID                      0ffcba84-b3aa-4d4c-802f-d6d490b4931b
Line Numbers                  

Raw Audit Messages            

node=localhost.localdomain type=AVC msg=audit(1264782076.860:52142): avc:  denied  { getattr } for  pid=17125 comm="abrt-hook-pytho" name="/" dev=dm-5 ino=2 scontext=unconfined_u:unconfined_r:abrt_helper_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem

node=localhost.localdomain type=SYSCALL msg=audit(1264782076.860:52142): arch=c000003e syscall=137 success=yes exit=128 a0=4021e1 a1=7fffbc62fa50 a2=fdf a3=7fffbc62f890 items=0 ppid=17113 pid=17125 auid=500 uid=500 gid=500 euid=490 suid=490 fsuid=490 egid=500 sgid=500 fsgid=500 tty=pts0 ses=2154 comm="abrt-hook-pytho" exe="/usr/libexec/abrt-hook-python" subj=unconfined_u:unconfined_r:abrt_helper_t:s0-s0:c0.c1023 key=(null)

(In reply to comment #10)
> OK, I've installed this from updates-testing, and am now getting this SELinux
> alert. Never seen it before, but the python update coincided with an
> selinux-policy update... so I'm not sure which one to blame!

Not sure; I'm not an expert on ABRT or SELinux.  My guess is that:
  - an unhandled Python traceback is happening on a python process somewhere on the system (perhaps caused by the python update, perhaps not).
  - ABRT has installed a handled for these (in the abrt-addon-python subpackage), so that it can potentially help you file a bug report (oh the irony)
  - ABRT tries to read the root directory, but is denied by SELinux policy.

Mark: Do you have any idea what the python traceback might have been? (and if it was caused by this python update - I'm a little concerned that I may have introduced a regression in something else here).  abrt-addon-python installs a small script into /usr/lib/python2.6/site-packages/sitecustomize.py which sets
  sys.excepthook
Does the ABRT GUI indicate what the exception was?  (the permissive domain means that whatever ABRT was trying to do wasn't stopped by SELinux).

CCing dwalsh for SELinux expertise: Dan, any ideas?  Should this be a separate bug?

(In reply to comment #11)
>   - ABRT has installed a handled for these (in the abrt-addon-python
"handled" should have read "handler", sorry.

This is the traceback from the ABRT gui. It occurs when exiting canto... should I open a new bug for this?

Summary: TBfe913b64 forking.py:106:poll:OSError: [Errno 10] No child processes

Traceback (most recent call last):
  File "/usr/lib64/python2.6/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/usr/lib64/python2.6/multiprocessing/util.py", line 262, in _exit_function
    for p in active_children():
  File "/usr/lib64/python2.6/multiprocessing/process.py", line 43, in active_children
    _cleanup()
  File "/usr/lib64/python2.6/multiprocessing/process.py", line 53, in _cleanup
    if p._popen.poll() is not None:
  File "/usr/lib64/python2.6/multiprocessing/forking.py", line 106, in poll
    pid, sts = os.waitpid(self.pid, flag)
OSError: [Errno 10] No child processes

Local variables in innermost frame:
flag: 1
self: <multiprocessing.forking.Popen object at 0x7f996ee34b10>

I've just noticed that the python update refers to os.waitpid (bug 552504), which also features in the above traceback. Is this the immediate cause?

SELinux alert has been reported and I believe is fixed in selinux-policy-3.6.32-78.fc12.noarch

Thanks for following up.

There are several things going on here:
- the linkage of the curses module (as per the subject of this bug), which I believe the update fixes
- the Python traceback seen when exiting canto, given in comment #13
- the ABRT SELinux issue when intercepting Python tracebacks mentioned in comment #10 and in comment #15

Feedback above confirms that the update does fix the curses linkage issue.

Mark: please can you upgrade to selinux-policy-3.6.32-78.fc12.noarch as mentioned in comment #15 and verify that it enables ABRT to correctly intercept the traceback without generating an SELinux AVC denial message.

Re comment #14: that worries me somewhat, however, the change for bug 552504 affects another user of os.waitpid (SocketServer.ForkingMixIn.collect_children), rather than the implementation of os.waitpid itself; this makes me think that it's another issue that was previously masked by the curses linkage problem, and that this should be filed as a separate bug.

Is anyone else seeing the traceback described in comment #13?  Is anyone else seeing other problems/possible regressions when running the new python rpms? (please update https://admin.fedoraproject.org/updates/F12/FEDORA-2010-0393 accordingly).  Thanks!

python-2.6.2-4.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.