Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 446112

Summary: TCP wrappers leave SIGALRM blocked when ident fails
Product: Red Hat Enterprise Linux 4 Reporter: Bryan Mason <nobody+bjmason>
Component: tcp_wrappersAssignee: Petr Lautrbach <plautrba>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: medium    
Version: 4.6CC: bmason, jwest, tao
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-14 21:06:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Proposed patch - 1 of 2
none
Proposed patch - 2 of 2 none

Description Bryan Mason 2008-05-12 19:25:53 UTC
+++ This bug was initially created as a clone of Bug #205129 +++

Description of problem:
When tcp wrappers try to query a remote ident server, which is blocked (e.g. by
iptables), it leaves SIGALRM blocked. This is especially bad for sshd, because
then whole session then runs with SIGALRM blocked.


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


How reproducible:
100%


Steps to Reproduce:
1. on ssh client: "iptables -I INPUT -p tcp --dport ident -j DROP"
2. on ssh server: configure TCP wrappers to do an ident lookup (e.g. add "sshd:
ALL@ALL" line to /etc/hosts.allow)
3a. on ssh client: "ssh user@server 'ps xs|grep $$|grep -v grep'"
or 3b. on ssh client: "ssh user@server", and in the ssh session run something
like this:

perl -e '$SIG{ALRM}=sub{print"ALARM\n";}; alarm 1; sleep 5'


Actual results:
3a: the "BLOCKED" column of SSH output contains SIGALRM (BLOCKED & 0x2000
is 0x2000 on Linux/x86_64 and Linux/i386).
3b: no message is printed.


Expected results:
3a: BLOCKED & 0x2000 should be zero
3b: the "ALARM\n" message should be printed.


Additional info:
In the following message, Wietse Venema suggests that tcp_wrappers code is
correct and the bug is added by third parties:
http://www.gatago.com/mailing/unix/openssh-dev/4854382.html

Debian bug #354855 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354855)
apparently contains a patch for this problem. (META: this bugzilla does not have
 Debian bug tracking system available in "External Bug Reference" list).

Comment 1 Bryan Mason 2008-05-12 19:28:17 UTC
Created attachment 305164 [details]
Proposed patch - 1 of 2

Comment 2 Bryan Mason 2008-05-12 19:28:33 UTC
Created attachment 305165 [details]
Proposed patch - 2 of 2

Comment 5 Jan Safranek 2008-05-30 11:26:45 UTC
These patches are already available in Fedora and nobody is complaining so far.

Comment 6 Jan Safranek 2008-05-30 11:27:44 UTC
Cloned to RHEL5 as bug #449090

Comment 7 Bryan Mason 2008-05-30 16:15:53 UTC
Bug 446103 already exists as a RHEL 5 version of this bug.  It was also cloned
from Bug 205129.

Comment 8 RHEL Program Management 2008-10-31 16:42:41 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 11 RHEL Program Management 2010-10-22 18:55:10 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.