Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 732081 - PAM does not correctly parse @users@@hosts netgroup syntax in /etc/security/access.conf
Summary: PAM does not correctly parse @users@@hosts netgroup syntax in /etc/security/a...
Alias: None
Product: Fedora
Classification: Fedora
Component: pam
Version: 15
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-19 17:55 UTC by Stephen Fromm
Modified: 2011-09-13 21:32 UTC (History)
1 user (show)

Fixed In Version: pam-1.1.4-4.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-09-07 03:27:21 UTC
Type: ---

Attachments (Terms of Use)

Description Stephen Fromm 2011-08-19 17:55:46 UTC
Description of problem:

I use /etc/security/access.conf to restrict what hosts users can log into and from where via SSH.  This is controlled via netgroups.  In access.conf, I have 
rules such as:

+ : @staff@@private-hosts :
+ : @staff@@bastion-hosts : ALL
- : ALL : ALL

The above should allow users in the netgroup staff to connect to hosts in the netgroup private-hosts from the above networks.  The same users
are allowed to connect to the bastion hosts from anywhere.  All other connections are denied.  This works in F13, F14, RHEL5, and RHEL6.

On Fedora 15 and pam-1.1.3-8, PAM does not correctly parse the @users@@hosts syntax and authorizes any authenticated user to connect to private-hosts from any location.  

If I drop the @@netgroup suffix, PAM will correctly limit connections to users in the netgroup staff.

+ : @staff :
+ : @staff : ALL

The manpage access.conf(5) says the @@netgroupname syntax should work:

       The @@netgroupname syntax is supported in the user pattern
       only and it makes the local system hostname to be passed to the
       netgroup match call in addition to the user name.

I can look up all of the above netgroups via 'getent netgroup <name>'.

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

Fedora 15 and pam-1.1.3-8.

How reproducible:


Steps to Reproduce:
1.  Create netgroups similar to:


2.  Update access.conf with rules similar to above.
3.  Update /etc/pam.d/sshd to refer to access.conf

account    required     pam_access.so accessfile=/etc/security/access.conf

4.  Update /etc/ssh/sshd_config and set 'UsePAM yes'.

Actual results:

Authenticated users (not just those in the staff netgroup) are authorized to connect to any host from any location.

Expected results:

Authenticated user in netgroup staff is authorized to connect to private-hosts from designated networks.  SSH connections from other locations are only allowed to hosts in bastion-hosts.

Additional info:

As stated above, this same configuration works on F13, F14, RHEL5, and RHEL6.

Comment 1 Fedora Update System 2011-08-25 17:38:51 UTC
pam-1.1.4-4.fc15 has been submitted as an update for Fedora 15.

Comment 2 Fedora Update System 2011-08-25 17:38:59 UTC
pam-1.1.4-4.fc16 has been submitted as an update for Fedora 16.

Comment 3 Fedora Update System 2011-08-26 14:19:33 UTC
Package pam-1.1.4-4.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing pam-1.1.4-4.fc16'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 4 Fedora Update System 2011-09-07 03:27:15 UTC
pam-1.1.4-4.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 5 Fedora Update System 2011-09-09 05:29:07 UTC
pam-1.1.4-4.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 6 Stephen Fromm 2011-09-13 21:32:13 UTC
Verified that this now works as intended.  Thank you!

Note You need to log in before you can comment on or make changes to this bug.