pam_access (1.7.0-1) improperly checks for group membership of a user.

Elizabeth · 2024-11-26 14:59:20

Hello, this is a half/continuation of a previous post I made on here in which I described an issue I encountered with logging in after upgrading pam to 1.7.0-1 (at around 19:00 on the 25th of November). After some help from fellow community member -thc, I managed to track down the issue to a line in the /etc/security/access.conf file.

The uncommented lines of the file as of finding the issue:

+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL

The line in question causing problems was "-:ALL:ALL." And after commenting it (and later uncommeting it but placing my user account and root as allowed explicitly) I was able to log in without issue.

The obvious question now is why didn't this work? I had had the same configuration of access.conf for more than a year, and the configuration itself is copied from the arch wiki, yet after the update it did not work.

To give more information on both the debugging process which lead me to this conclusion, as well as to give the information needed for contribution, I will provide several examples of journalctl log messages which are relevant to the workings of pam_access. (The messages were printed out only after passing the debug parameter to pam_access.so in /etc/pam.d/system-login)

First: the line specifying the module in /etc/pam.d/system-login:

account    required   pam_access.so debug

access.conf (1):

+:(wheel) (adm):LOCAL
-:ALL:ALL

journal logs (1):

Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): from_match=2, "tty2"
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): string_match: tok=ALL, item=tty2
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): from_match: tok=ALL, item=tty2
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): list_match: list=ALL, item=[username]
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): user_match=2, "[username]"
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): string_match: tok=ALL, item=[username]
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): user_match: tok=ALL, item=[username]
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): list_match: list=ALL, item=[username]
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): line 5: - : ALL : ALL
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): user_match=0, "[username]"
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): group_match: grp=(adm), user=[username]
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): user_match: tok=(adm), item=[username]
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): group_match: grp=(wheel), user=[username]
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): user_match: tok=(wheel), item=[username]
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): list_match: list=(wheel) (adm), item=[username]
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): line 2: + : (wheel) (adm) : LOCAL
Nov 26 15:17:09 [system-name] login[9354]: pam_access(login:account): login_access: user=[username], from=tty2, file=/etc/security/access.conf

This was the original scenario under which I could not log in (though with a slightly compressed syntax which makes no difference for the result). The logs show pam_access searching trough each name in the line, and failing to match my user to any of the groups, despite the fact that running "groups [username]" yields "wheel adm [username]."

The second scenario goes over the workaround I've implemented for the time being.

access.conf (2):

+:(wheel) (adm):LOCAL
+:[username] root:LOCAL
-:ALL:ALL

journal logs (2):

Nov 26 15:28:15 [system-name] login[11780]: pam_unix(login:session): session opened for user [username](uid=1000) by [username](uid=0)
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): from_match=1, "tty2"
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): string_match: tok=LOCAL, item=tty2
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): from_match: tok=LOCAL, item=tty2
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): list_match: list=LOCAL, item=[username]
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): user_match=1, "[username]"
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): string_match: tok=[username], item=[username]
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): user_match: tok=[username], item=[username]
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): list_match: list=[username] root, item=[username]
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): line 3: + : [username] root : LOCAL
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): user_match=0, "[username]"
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): group_match: grp=(adm), user=[username]
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): user_match: tok=(adm), item=[username]
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): group_match: grp=(wheel), user=[username]
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): user_match: tok=(wheel), item=[username]
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): list_match: list=(wheel) (adm), item=[username]
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): line 2: + : (wheel) (adm) : LOCAL
Nov 26 15:28:15 [system-name] login[11780]: pam_access(login:account): login_access: user=[username], from=tty2, file=/etc/security/access.conf

The final scenario considers what happened when I specified the user's default group as a name. Weirdly, this worked fine, although it can be seen from the logs that in any case, neither (wheel) nor (adm) would match.

access.conf (3):

+:(wheel) (adm):LOCAL
+:([username]) root:LOCAL
-:ALL:ALL

journal logs (3):

Nov 26 15:39:53 [system-name] login[13642]: pam_unix(login:session): session opened for user [username](uid=1000) by [username](uid=0)
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): from_match=1, "tty2"
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): string_match: tok=LOCAL, item=tty2
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): from_match: tok=LOCAL, item=tty2
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): list_match: list=LOCAL, item=[username]
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): user_match=1, "[username]"
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): group_match: grp=([username]), user=[username]
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): user_match: tok=([username]), item=[username]
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): list_match: list=([username]) root, item=[username]
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): line 3: + : ([username]) root : LOCAL
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): user_match=0, "[username]"
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): group_match: grp=(adm), user=[username]
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): user_match: tok=(adm), item=[username]
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): group_match: grp=(wheel), user=[username]
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): user_match: tok=(wheel), item=[username]
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): list_match: list=(wheel) (adm), item=[username]
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): line 2: + : (wheel) (adm) : LOCAL
Nov 26 15:39:53 [system-name] login[13642]: pam_access(login:account): login_access: user=[username], from=tty2, file=/etc/security/access.conf

Seemingly, the latest update broke some part of querying the /etc/group file for groups that the user is explicitly stated to be in, as my group file (omitting irrelevant lines) looks like this:

adm:x:999:daemon,[username]
wheel:x:998:[username],root
[username]:x:1000:

I tried to dig around in the source files of PAM on GitHub, but I quickly found that I'm out of my depth in that regard, and could not find any issues. (looking at the most recent commits (1) and (2) did not yield any results too). I am writing in this in the hopes that other community members will be able to figure out what is going on here, and should the issue be with the source code, notify the maintainers and contributors of PAM.

Last edited by Elizabeth (2024-11-26 15:06:46)

namelessone · 2024-11-26 18:23:40

I can confirm I see the same issue. In my access.conf I had:

-:ALL EXCEPT (wheel) shutdown sync:LOCAL

and I got locked out after the pam update. I switched to

+:[username]:LOCAL
-:ALL:ALL

as a workaround.

This smells like a pam problem, but I'd probably start by notifying the package maintainers listed at https://archlinux.org/packages/core/x86_64/pam/

Elizabeth · 2024-11-27 02:25:10

namelessone wrote:

I can confirm I see the same issue. In my access.conf I had:
-:ALL EXCEPT (wheel) shutdown sync:LOCAL
and I got locked out after the pam update. I switched to
+:[username]:LOCAL
-:ALL:ALL
as a workaround.
This smells like a pam problem, but I'd probably start by notifying the package maintainers listed at https://archlinux.org/packages/core/x86_64/pam/

Unfortunately account registration for gitlab is currently not possible, and I do not have an account which I could report the bug with.

namelessone · 2024-11-27 02:44:42

yeah...I don't have one either :'(

I put in a request for an account, so I'll see if that goes anywhere...

seth · 2024-11-27 08:28:21

https://github.com/linux-pam/linux-pam/ … d4d36669ca ?

Elizabeth · 2024-11-27 12:29:01

seth wrote:

https://github.com/linux-pam/linux-pam/ … d4d36669ca ?

Could it be that? Thats from 2019 and it was working fine for me up until a few days ago. So surely if that was the cause it should've appeared sooner?

seth · 2024-11-27 17:18:08

No, sorry - of course not.
I checked the function in pam_access, clicked through history of files w/ seemingly relevant calls and at some point skipped the year and just saw "Nov. 5th"
Fuck.

Starting point was actually https://github.com/linux-pam/linux-pam/ … cae3465243 - does it work if you issue a GID instead of the group name?

Elizabeth · 2024-11-27 18:00:04

I have tested whether it works with adm and wheel's GID's before, but not whether it will work if I put in my default group GID, and the results are interesting.

access.conf (4):

+:(998) (999):LOCAL
+:(1000) root:LOCAL
-:ALL:ALL

journal logs (4):

Nov 27 18:55:05 [system-name] login[32529]: Permission denied
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): access denied for user `[username]' from `tty2'
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): from_match=2, "tty2"
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): string_match: tok=ALL, item=tty2
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): from_match: tok=ALL, item=tty2
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): list_match: list=ALL, item=[username]
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): user_match=2, "[username]"
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): string_match: tok=ALL, item=[username]
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): user_match: tok=ALL, item=[username]
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): list_match: list=ALL, item=[username]
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): line 7: - : ALL : ALL
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): user_match=0, "[username]"
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): string_match: tok=root, item=[username]
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): user_match: tok=root, item=[username]
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): group_match: grp=(1000), user=[username]
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): user_match: tok=(1000), item=[username]
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): list_match: list=(1000) root, item=[username]
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): line 5: + : (1000) root : LOCAL
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): user_match=0, "[username]"
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): group_match: grp=(999), user=[username]
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): user_match: tok=(999), item=[username]
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): group_match: grp=(998), user=[username]
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): user_match: tok=(998), item=[username]
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): list_match: list=(998) (999), item=[username]
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): line 2: + : (998) (999) : LOCAL
Nov 27 18:55:05 [system-name] login[32529]: pam_access(login:account): login_access: user=[username], from=tty2, file=/etc/security/access.conf

Seemingly the GID search functionality is fully broken, unlike the group name one which seems to work for the user's default group?

seth · 2024-11-27 18:19:31

Skip the brackets, https://github.com/linux-pam/linux-pam/ … 7568cfR618 will return "NO" for everything that's not a number.

Elizabeth · 2024-11-27 18:27:15

The brackets are necessary because pam_access will assume its a UID if they arent present, see this if else chain for the relevant code.

seth · 2024-11-27 18:44:45

It's actually sanitized at https://github.com/linux-pam/linux-pam/ … 7568cfR737 but yes. Unfortunately not that easy.

Also pam_modutil_user_in_group_nam_nam has been used previously and is still the first check.
Feel free to look on - I'll have to break until tomorrow.

progandy · 2024-11-27 19:01:53

seth wrote:

Skip the brackets, https://github.com/linux-pam/linux-pam/ … 7568cfR618 will return "NO" for everything that's not a number.

You found the bad commit. If you look closely, they failed to keep the parameter order:

static int group_name_or_gid_match(pam_handle_t *pamh, const char *tok, const char *usr, int debug)

vs

group_name_or_gid_match (pamh, usr, tok, debug)

Last edited by progandy (2024-11-27 19:02:16)

Elizabeth · 2024-11-27 19:05:29

Thank you for finding the bug! I will open the issue on the github page

Arch Linux

#1 2024-11-26 14:59:20

pam_access (1.7.0-1) improperly checks for group membership of a user.

#2 2024-11-26 18:23:40

Re: pam_access (1.7.0-1) improperly checks for group membership of a user.

#3 2024-11-27 02:25:10

Re: pam_access (1.7.0-1) improperly checks for group membership of a user.

#4 2024-11-27 02:44:42

Re: pam_access (1.7.0-1) improperly checks for group membership of a user.

#5 2024-11-27 08:28:21

Re: pam_access (1.7.0-1) improperly checks for group membership of a user.

#6 2024-11-27 12:29:01

Re: pam_access (1.7.0-1) improperly checks for group membership of a user.

#7 2024-11-27 17:18:08

Re: pam_access (1.7.0-1) improperly checks for group membership of a user.

#8 2024-11-27 18:00:04

Re: pam_access (1.7.0-1) improperly checks for group membership of a user.

#9 2024-11-27 18:19:31

Re: pam_access (1.7.0-1) improperly checks for group membership of a user.

#10 2024-11-27 18:27:15

Re: pam_access (1.7.0-1) improperly checks for group membership of a user.

#11 2024-11-27 18:44:45

Re: pam_access (1.7.0-1) improperly checks for group membership of a user.

#12 2024-11-27 19:01:53

Re: pam_access (1.7.0-1) improperly checks for group membership of a user.

#13 2024-11-27 19:05:29

Re: pam_access (1.7.0-1) improperly checks for group membership of a user.

Board footer