Bug 772982 - Exception TypeError: "'NoneType' object is not callable" in <function _removeHandlerRef at 0xb75c96bc> ignored
Summary: Exception TypeError: "'NoneType' object is not callable" in <function _remove...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: setroubleshoot
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-10 15:33 UTC by Wendell Baker
Modified: 2013-11-20 14:17 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-11-20 14:17:11 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Wendell Baker 2012-01-10 15:33:55 UTC
Description of problem:

This problem pertains to the failure to run setroubleshootd

Scenario:
install rawhide
create a user account wbaker, uid=600
ssh into rawhide from elsewhere
sshd on rawhide refuses to accept known-working authorized_keys2
SElinux is implicated
see /var/log/message with a failure to start setroubleshootd

this report pertains to the failure to run setroubleshootd as indicated by the python exception shown

Jan 10 07:17:02 rawhide dbus[855]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper)
Jan 10 07:17:02 rawhide dbus-daemon[855]: dbus[855]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper)
Jan 10 07:17:04 rawhide dbus[855]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd'
Jan 10 07:17:04 rawhide dbus-daemon[855]: dbus[855]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd'
Jan 10 07:17:18 rawhide dbus-daemon[855]: Exception TypeError: "'NoneType' object is not callable" in <function _removeHandlerRef at 0xb75c96bc> ignored


Version-Release number of selected component (if applicable):

rpm -q kernel-PAE openssh dbus setroubleshoot | sort
dbus-1.4.10-3.fc17.i686
kernel-PAE-3.2.0-0.rc7.git3.1.fc17.i686
kernel-PAE-3.2.0-2.fc17.i686
openssh-5.9p1-14.fc17.i686
setroubleshoot-3.0.45-1.fc17.i686


How reproducible:

very

Steps to Reproduce:
1. install rawhide
2. create a user account 
3. create a /home/$USER/.ssh/authorized_keys2 file
4. ssh into the host as the user with the keys in hand
  
Actual results:

failure to ssh in

Expected results:

ssh works, as on Verne

Additional info:


The SElinux labels aren't right on /home/wbaker/.ssh on Rawhide
The SElinux labels are correct on /home/wbaker/.ssh on Verne

[root@rawhide ~]# ls -alsdZ /home/wbaker /home/wbaker/.ssh /home/wbaker/.ssh/authorized_keys2 
drwxr-xr-x. wbaker wbaker unconfined_u:object_r:home_root_t:s0 /home/wbaker
drwxr-xr-x. wbaker wbaker unconfined_u:object_r:home_root_t:s0 /home/wbaker/.ssh
-rw-r--r--. wbaker wbaker unconfined_u:object_r:home_root_t:s0 /home/wbaker/.ssh/authorized_keys2

[root@verne ~] #
ls -alsdZ /home/wbaker /home/wbaker/.ssh /home/wbaker/.ssh/authorized_keys2 
drwx------. wbaker wbaker unconfined_u:object_r:user_home_dir_t:s0 /home/wbaker
drwxr-xr-x. root   root   unconfined_u:object_r:ssh_home_t:s0 /home/wbaker/.ssh
-rw-r--r--. root   root   unconfined_u:object_r:ssh_home_t:s0 /home/wbaker/.ssh/authorized_keys2



The user account was created crudely with the moral equivalent of the following (which works fine on F16.Verne):

cat <<REALLY-EOF-REALLY | ssh root@rawhide
	groupadd -g 500 wbaker
	useradd -u 500 -g wbaker wbaker
	usermod -c 'Wendell Craig Baker' wbaker
	# no group list (save that for later when the full account set comes in)
	usermod -p 'non-secret-password-gobletygook' wbaker
	mkdir -p /home/wbaker/.ssh
	cat << EOF >> /home/wbaker/.ssh/authorized_keys2
... some known-working ssh keys here...
EOF

	chmod 755 /home/wbaker/.ssh
	chmod 644 /home/wbaker/.ssh/authorized_keys2
REALLY-EOF-REALLY

This complaint pertains to the failure to start setroubleshootd, not to the failure to label /home/wbaker/.ssh (though that is an issue as well, clearly).

The workaround:

[root@rawhide ~]# /sbin/restorecon -v -v -R /home/wbaker/.ssh
/sbin/restorecon reset /home/wbaker/.ssh context unconfined_u:object_r:home_root_t:s0->unconfined_u:object_r:ssh_home_t:s0
/sbin/restorecon reset /home/wbaker/.ssh/authorized_keys2 context unconfined_u:object_r:home_root_t:s0->unconfined_u:object_r:ssh_home_t:s0

[root@rawhide ~]# ls -alsdZ /home/wbaker /home/wbaker/.ssh /home/wbaker/.ssh/authorized_keys2 
drwxr-xr-x. wbaker wbaker unconfined_u:object_r:home_root_t:s0 /home/wbaker
drwxr-xr-x. wbaker wbaker unconfined_u:object_r:ssh_home_t:s0 /home/wbaker/.ssh
-rw-r--r--. wbaker wbaker unconfined_u:object_r:ssh_home_t:s0 /home/wbaker/.ssh/authorized_keys2

now "ssh into rawhide as user wbaker works"

Comment 1 Daniel Walsh 2012-02-14 19:58:54 UTC
cat <<REALLY-EOF-REALLY | ssh root@rawhide
 groupadd -g 500 wbaker
 useradd -u 500 -g wbaker wbaker
 usermod -c 'Wendell Craig Baker' wbaker
 # no group list (save that for later when the full account set comes in)
 usermod -p 'non-secret-password-gobletygook' wbaker
 mkdir -p /home/wbaker/.ssh
 cat << EOF >> /home/wbaker/.ssh/authorized_keys2
... some known-working ssh keys here...
EOF

 chmod 755 /home/wbaker/.ssh
 chmod 644 /home/wbaker/.ssh/authorized_keys2
 restorecon -R -v /home/wbaker
REALLY-EOF-REALLY

Should fix your labeling problem.

I just pushed an updated setroubleshoot that seems to be working correctly on my machine.  Could you try it out.

setroubleshoot-3.1.3-1.fc17.x86_64

Comment 2 Fedora End Of Life 2013-04-03 20:25:12 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 3 Cole Robinson 2013-11-20 14:17:11 UTC
No response for months and its been in MODIFIED that whole time, closing as CURRENTRELEASE


Note You need to log in before you can comment on or make changes to this bug.