https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286014
Bug ID: 286014
Summary: login_access.c -- logging bug
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: [email protected]
Reporter: [email protected]
Created attachment 259441
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=259441&action=edit
Patch
By default, the PAM login_access module checks tokens in /etc/login.access
against both user names and group names. If a token doesn't match the
current user, it tries to look for a group with that name. If that fails,
it logs the following message:
group not found: <FOO>
However, <FOO> is *not* the group name that hasn't been found, it's the
name of the current user. This is confusing. In fact, it caused me to
waste quite some time searching for a problem that didn't exist, very
much like the fellows in this forum thread:
https://forums.freebsd.org/threads/su-group-not-found-root.90682/
It can be reproduced easily: Add a line at the beginning of the file
/etc/login.access:
+ : yedi_masters : ALL
(You can use any name that doesn't exist in /etc/group.)
Then perform a login operation, e.g. login on a virtual console,
or just use the "login" command in an existing shell, and look at
/var/log/messages. In my case, I see:
login[12345]: group not found: olli
which is confusing because there *is* a group named "olli" of course.
It *should* log:
login[12345]: group not found: yedi_masters
The bug is in lib/libpam/modules/pam_login_access/login_access.c.
It was probably caused by a copy&paste oversight, because there is a
very similar syslog() line nearby in the code that logs the user name.
I've attached a trivial patch that fixes it. The patch has been tested
with CURRENT, but it should apply cleanly as well to all other branches
that are currently supported, plus stable/12. The code in question
hasn't been touched in more than five years.
--
You are receiving this mail because:
You are the assignee for the bug.
