From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; GIL 2; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30) Description of problem: If a client host is specified in a netgroup which is a member of another netgroup, which in turn is granted access via hosts.equiv or .rhosts, the client host is denied access via rsh/rlogin/rcp without a password. In other words, if netgroup "linux" contains netgroup "rhel5", and netgroup rhel5 contains host "server1" and hosts.equiv has the entry "+@linux", rsh/rlogin/rcp fail. If however, the hosts.equiv contains "+@rhel5" OR netgroup "linux" contains "server1", then server1 will be allowed access. This is contrary to expected behavior, as seen on RHEL3, HPUX, Solaris. It almost appears as if the innetgr() call is not recursing. Version-Release number of selected component (if applicable): pam-0.99.6.2-3.14.el5 How reproducible: Always Steps to Reproduce: 1. Create netgroup "linux" as: linux rhel5 2. create netgroup "rhel5" as: rhel5 (server1,,) 3. Add netgroup entry for "linux" to /etc/hosts.equiv: +@linux 4) attempt to rsh/rlogin/rcp from server1 - access is denied Actual Results: Access denied: Aug 16 09:40:11 cpafiszi rlogind[18783]: pam_rhosts_auth(rlogin:auth): denied to cokm@cpafiszk as cokm: access not allowed Expected Results: Access allowed Additional info: We are using RFC2307 (NIS data stored in LDAP) rather than a standard ypserver, but this behavior is only experienced on RHEL5.
pam_rhosts_auth just calls innetgr which is glibc function.
Please close - Not A Bug. After looking at the source (pam_rhosts_auth.c) I created a small C program (calling innetgr) and validated that I was only seeing the problem with a particular netgroup. On further investigation, I found one of my LDAP replicas was out of sync due to an earlier error.