Red Hat Bugzilla – Bug 174146
RHEL3: pam_access.so does not work with rexec for IP/hostname restriction
Last modified: 2017-05-22 07:48:15 EDT
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
# 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
Version-Release number of selected component (if applicable):
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:
Or if I change the file to be:
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'
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.
This is clearly a problem in rexec not pam_access.
Here are more information from /var/log/messages in rexecd server:
Nov 25 14:01:25 rexecd_server_name /usr/sbin/in.rexecd: connect from
Nov 25 14:01:25 rexecd_server_name pam_access: 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.
You're right. It doesn't set pam_set_item(pamh, PAM_RHOST, host);
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?
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.
The problem has been fixed in FC4 and FC5.
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.
It's definitely the rsh package problem only. There's no problem in kernel.
I just tried it, but it is not working in my case. I downloaded this Fedora
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?
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).
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.
From User-Agent: XML-RPC
Refer to bug#174146 for details on this case.
Karel Zak (firstname.lastname@example.org) 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
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.