Bug 174146

Summary: RHEL3: pam_access.so does not work with rexec for IP/hostname restriction
Product: Red Hat Enterprise Linux 3 Reporter: Hai Wu <hxwu>
Component: rshAssignee: Karel Zak <kzak>
Status: CLOSED ERRATA QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2006-0231 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-03-29 20:55:24 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:
Bug Depends On:    
Bug Blocks: 178252, 187539    

Description Hai Wu 2005-11-25 04:38:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

Description of problem:
We need to restrict rexec access by IP/hostname. But the combo of pam_access and rexec does not work together for this purpose. 

The following are the conf files:
# cat /etc/pam.d/rexec
#%PAM-1.0
# For root login to succeed here with pam_securetty, "rexec" must be
# listed in /etc/securetty.
auth       required     pam_nologin.so
auth       required     pam_securetty.so
auth       required     pam_env.so
auth       required     pam_stack.so service=system-auth
account    required     pam_access.so accessfile=/etc/pam.d/rexec.access
account    required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth

# cat /etc/pam.d/rexec.access
+:user1:testhost1
-:ALL:ALL

Version-Release number of selected component (if applicable):
pam-0.75-62, rsh-server-0.17-17

How reproducible:
Always

Steps to Reproduce:
1. From 'testhost1' server, type command: rexec -ad -l user1 -p user1_password rexecd_server_name '/bin/touch /tmp/testing1.txt'
2. The above will fail every time, file '/var/log/message' would show that pam_access says that "access denied for user `user1' from `rexec'"
3. But if I change the file '/etc/pam.d/rexec.access' to be:
+:user1:rexec
-:ALL:ALL

Or if I change the file to be:
+:user1:ALL
-:ALL:ALL

Then the rexec will always suceed.
  

Actual Results:  rexec: Host = rexecd_server_name
rexec: Command to execute = /bin/touch /tmp/testing1.txt
testinghost1: No such file or directory
rexec: Error in rexec system call,
rexec: (The following system error may itself be in error)
rexec: No such file or directory

Expected Results:  /tmp/testing1.txt should have been created in server 'rexecd_server_name'

Additional info:

I also tested this pam/rsh-server combo for RHEL ES3U6 (as the rexecd_server), it also failed in the same way. It seems rexec could not work well with pam_access.so.

Comment 1 Tomas Mraz 2005-11-25 12:32:55 UTC
This is clearly a problem in rexec not pam_access.


Comment 2 Hai Wu 2005-11-25 20:34:25 UTC
Here are more information from /var/log/messages in rexecd server:
Nov 25 14:01:25 rexecd_server_name /usr/sbin/in.rexecd[20200]: connect from
testhost1
Nov 25 14:01:25 rexecd_server_name pam_access[20200]: access denied for user
`asrc' from `rexec'

The messages indicates that in.rexecd knows that the connection came from
'testhost1', but pam_access doesn't know the source of the connection, it just
knew it came from 'rexec'. Not sure if this would be helpful.

Comment 3 Karel Zak 2005-11-28 14:14:56 UTC
You're right. It doesn't set pam_set_item(pamh, PAM_RHOST, host);
  

Comment 4 Hai Wu 2005-11-28 16:47:37 UTC
We have a few RedHat Enterprise Linux servers (with subscriptions) here, 
waiting for this bug to be fixed shortly. Otherwise, we are seriously 
considering that we might have to use Windows servers to replace these Linux 
boxes, since we have a tight project schedule. Is it possible for you to have 
it fix soon?

Thanks.

Comment 5 Tomas Mraz 2005-11-28 17:17:37 UTC
Well, then please could you use your paid subscription support issue tracker to
report the bug. It would raise the chances that it will be fixed soon.

Please mention this bug number in the tracker entry.


Comment 6 Karel Zak 2005-11-29 08:41:03 UTC
The problem has been fixed in FC4 and FC5.

Comment 7 Hai Wu 2005-11-29 09:00:44 UTC
That's a good news for us! It seems to me that FC4 and FC5 are only for 2.6
kernel. I hope RedHat could backport this fix to RHEL 3(2.4 kernel). 

I also requested Dell support to upgrade this case to RedHat, since we bought
RedHat subscription through Dell.

Thanks,
Hai

Comment 8 Karel Zak 2005-11-29 09:07:42 UTC
It's definitely the rsh package problem only. There's no problem in kernel.

Comment 9 Hai Wu 2005-11-29 09:30:50 UTC
I just tried it, but it is not working in my case. I downloaded this Fedora
package at
http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/SRPMS/rsh-0.17-32.src.rpm,
compiled and installed on RHEL ES 3 Update 6, then I used the old
/etc/pam.d/rexec file (I am not sure if I can use the new /etc/pam.d/rexec that
comes with rsh-server package, since it has new PAM syntax). The testing results
are the same as before, still not working. 

Does it mean this new version would only work with the new PAM version in FC4 & FC5?

Thanks,

Comment 10 Karel Zak 2005-11-29 10:22:32 UTC
Hai, you need to recompile and test the latest version: rsh-0.17-33
(FC5/development) or rsh-0.17-29.1 (FC4). I fixed it yesterday, so it's possible
that it isn't on all Fedora mirrors yet.

You have to use old /etc/pam.d/rexec (or I think that in FC4 is old version of
PAM syntax too).

Comment 11 Hai Wu 2005-11-29 15:56:26 UTC
Thanks! I tested the source RPM package of rsh-0.17-29.1 on RHEL3U6, and it
works! I have to use the source RPM since the binary one complains about some
libc dependency on RHEL3. 

Now it is a matter of time for this package to be formally ported to RHEL3. 

Thanks!
Hai

Comment 12 Issue Tracker 2005-11-29 21:26:32 UTC
From User-Agent: XML-RPC

Refer to bug#174146 for details on this case. 



Karel Zak (kzak) has been working on this problem with the
customer. The problem has been identified to be in the rsh code which has
been fixed in FC4 and FC5. Customer has recompiled and tested rsh-0.17-29.1
on RHEL3U6 and it fixes his problem.



They are requesting RH to backport this fix into RHEL3 and release this fix
to provide a supported solution. 



SEG, Please escalate to engineering.


Issue escalated to Support Engineering Group by: sbenjamin.
sbenjamin assigned to issue for Dell
Bugzilla id 174146 added to issue.
Category set to: Services

Internal Status set to 'Waiting on SEG'
Status set to: Waiting on Tech

This event sent from IssueTracker by sbenjamin
 issue 83956

Comment 18 Red Hat Bugzilla 2006-03-29 20:55:24 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0231.html