Red Hat Bugzilla – Bug 168383
mountd / tcp_wrappers not honoring NIS netgroup
Last modified: 2010-06-07 01:26:09 EDT
Description of problem:
Via tcp_wrappers and NIS we restrict access to desktop client NFS shares to
members of an NIS netgroup called @trusted_clients. The Red Hat 4 mountd does
not honor netgroup membership. As a work around I had to switch to IP based
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. NIS directory service required. Netgroup should contain a list of trusted
2. Tcp_wrappers should be configured as such:
ALL EXCEPT sshd: 127.0.0.1 @trusted_clients
ALL: ALL: spawn (/usr/sbin/safe_finger -l @%h | /bin/mail -s %d-%h root) &
3. Attempt to mount an Red Hat 4 NFS share from a trusted member of netgroup.
On NFS client: Permission denied.
On RedHat 4 NFS share server: Tcp_wrappers / mountd will deny the access request
and email the output of safe_finger to firstname.lastname@example.org.
Note: The safe_finger output reports the client via IP, short hostname, and
fully qualified DNS hostname:
The NFS mount should succeed.
As a work around I setup tcp_wrappers /etc/hosts.allow as follows:
ALL EXCEPT mountd sshd: 127.0.0.1 @trusted_clients
I understand that RedHat advises customers to use IPTables instead of TCP
Wrappers. Please note that this suggestion is not valid for a corporate LAN
environment. We are trying to prevent Windows clients from NFS mounting Linux
shares. The Windows and Linux clients are in the same IP space / pool.
We would have to readdress to accomidate IP TAbles usage. That is not practical
because boxes often switch to / from Windows and other boxes are dual booted.
- Joe Kotran
Even thugh this bug report is 2 years old, I gonna give it a try.
I think I encountered the same issue with sshd service.
I set up netgroup to use an ldap backend.
I found out that I needed to reload the service after the change were made in
/etc/nsswitch.conf in order to have tcpd resolving the netgroup.
This does not happen on a fedora 7. any changes made are directly taken into
account (which is the expected behaviour).
Can you confirm this?