Bug 104553 - [patch] [request] Add login group support to login.access(5)
Summary: [patch] [request] Add login group support to login.access(5)
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 7.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-18 23:20 UTC by Nick Barkas
Modified: 2017-12-31 22:37 UTC (History)
0 users

See Also:


Attachments
file.diff (2.37 KB, patch)
2006-10-18 23:20 UTC, Nick Barkas
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Barkas 2006-10-18 23:20:15 UTC
I use /etc/login.access to control access to machines based on what groups users
are in. Only certain groups are permitted access. If a user is a member of a
group, but it is their primary or login group, login.access will not permit them
to log in. Group based access control only works if the group(s) given in
/etc/login.access have the users in their **gr_mem struct member.

This behavior is documented in login.access(5) and comments in
/etc/login.access, but it would be nice if the group access control worked for
login groups.

Fix: Here are patches against -CURRENT to code and documentation that will fix this:
How-To-Repeat: Put a line like this in /etc/login.access:
-:ALL EXCEPT wheel foogroup:ALL

If user foo has a password file entry like this:
foo:*:1001:1001:Test User:/home/foo:/bin/sh

and foogroup has a group file entry like this:
foogroup:*:1001:

user foo will not be able to log in, despite the fact that the user is in group
foogroup.
Comment 1 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:13 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped