You are not logged in.
Hello, I have encountered a strange error following the latest pam update (to 1.7.0-1)
After I updated my system and rebooted it (following a lengthy play session), I found that each time I would try to login with my username and password I would get a message saying "Permission denied", even if I tried to log in as root.
Weirdly, this error does not come up if I type in the wrong password.
After some poking around in the system's journal trough a flash drive, I found the following lines:
[...] login[3417]: Permission denied
[...] login[3417]: pam_access(login:account): access denied for user `[username]' from `tty1'
,
After some googling, I learned to check the etc/pam.d/login file, which looked like this:
#%PAM-1.0
auth requisite pam_nologin.so
auth include system-local-login
account include system-local-login
session include system-local-login
password include system-local-login
,
Cross-referencing that with the etc/pam.d/login file of the flash drive,
#%PAM-1.0
auth required pam_securetty.so
auth requisite pam_nologin.so
auth include system-local-login
account include system-local-login
session include system-local-login
password include system-local-login
Seemignly, after updating the package the line
auth required pam_securetty.so
Had disappeared.
I am yet to try editing the file to put in the missing line since I am not confident that it is the actual issue, and I am scared of breaking something if I do.
I would like to ask whether editing the file in this way is safe, and what could have caused this in the first place (I know with certainty that I did not edit the file on my own, since I closed my shell after updating the system)
Thank you in advance for your patience.
Note: I am certain that the issue arose after the pam update, as confirned by the pacman logs.
Last edited by Elizabeth (2024-11-26 13:08:08)
Offline
Small update: while checking for differences between files in my machine's pam.d directory and the flash drive's, I found that I had mistyped a line way back when I was first setting up my system
The line in question was supposed to be (in system-login)
auth optional pam_faildelay.so delay=4000000
But I had instead written
uth optional pam_faildelay.so delay=4000000
Now that I have identified this issue, I also wish to comment that this had been appearing in the system journal as
[...] login[3417]: PAM (login) illegal module type: uth
Repeated four lines in a row.
I didn't mention this, as it had been appearing even before the login issue arose, though having now identified it, I do wish to add this information, as it might help in diagnosting the root of this issue. (Perhaps the illegal module somehow caused it to omitt the needed line or something?)
Offline
Update: I bit the bullet and added the missing line in manually. It did not work. The journal still reports the same error:
[...] login[3417]: Permission denied
[...] login[3417]: pam_access(login:account): access denied for user `[username]' from `tty1'
Quite frankly, I am at a loss for what to do, and I need my system to work very soon, so I hope that some good soul will help me out.
Last edited by Elizabeth (2024-11-26 03:21:51)
Offline
Have you tried to "crawl" the pam subsystem and the needed modules/files?
The error points to "login:account".
In my case the pam file "login" leads to
account include system-local-login
->
account include system-login
->
account required pam_access.so # reads "/etc/security/access.conf"
account required pam_nologin.so # does "/etc/nologin" exist?
account include system-auth
->
-account [success=1 default=ignore] pam_systemd_home.so
account required pam_unix.so # reads "/etc/shadow"
account optional pam_permit.so
account required pam_time.so # reads "/etc/security/time.conf"
Do any of those files exist and have sufficient permissions?
Offline
Have you tried to "crawl" the pam subsystem and the needed modules/files?
The error points to "login:account".
In my case the pam file "login" leads to
account include system-local-login -> account include system-login -> account required pam_access.so # reads "/etc/security/access.conf" account required pam_nologin.so # does "/etc/nologin" exist? account include system-auth -> -account [success=1 default=ignore] pam_systemd_home.so account required pam_unix.so # reads "/etc/shadow" account optional pam_permit.so account required pam_time.so # reads "/etc/security/time.conf"
Do any of those files exist and have sufficient permissions?
I've checked each file and from what I can see only /etc/nologin is absent.
I would also like to ask what counts as sufficent perms?
Offline
Note: I do remember seeing filesystem repairs running when I started up the system that day, could it be that one of the modules got corrupted in the process or was corrupted?
Offline
After enabling debugging for the relevant modules, I found more logs from pam_acess:
[...] login[3414]: pam_access(login:account): Permission denied
[...] login[3414]: pam_access(login:account): acess denied for user `[username]' from `tty1'
[...] login[3414]: pam_access(login:account): from_match=2, "tty1"
[...] login[3414]: pam_access(login:account): string_match: tok=ALL, item=tty1
[...] login[3414]: pam_access(login:account): from_match: tok=ALL, item=tty1
[...] login[3414]: pam_access(login:account): list_match: list=ALL, item=[username]
[...] login[3414]: pam_access(login:account): user_match=2, "[username]"
[...] login[3414]: pam_access(login:account): string_match: tok=ALL, item="[username]"
[...] login[3414]: pam_access(login:account): line 4: - : ALL : ALL
[...] login[3414]: pam_access(login:account): user_match=0, "[username]"
[...] login[3414]: pam_access(login:account): group_match: grp=(adm), user=[username]
[...] login[3414]: pam_access(login:account): user_match: tok=(adm), item=[username]
[...] login[3414]: pam_access(login:account): list_match: list=(adm), item=[username]
[...] login[3414]: pam_access(login:account): line 3: + : (adm) : LOCAL
[...] login[3414]: pam_access(login:account): user_match=0, "[username]"
[...] login[3414]: pam_access(login:account): group_match: grp=(wheel), user=[username]
[...] login[3414]: pam_access(login:account): user_match: tok=(wheel), item=[username]
[...] login[3414]: pam_access(login:account): list_match: list=(wheel), item=[username]
[...] login[3414]: pam_access(login:account): line 2: + : (wheel) : LOCAL
[...] login[3414]: pam_access(login:account): login_access: user=[username], from=tty1, file=/etc/security/access.conf
Seeing as it acess the access.conf file, I will put the uncommented lines in here:
+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL
Note: I have checked the /etc/group file and my user is a member of both the wheel and adm groups.
Last edited by Elizabeth (2024-11-26 11:52:50)
Offline
I've checked each file and from what I can see only /etc/nologin is absent.
I would also like to ask what counts as sufficent perms?
Owner 0:0 mode 644.
Note: I do remember seeing filesystem repairs running when I started up the system that day, could it be that one of the modules got corrupted in the process or was corrupted?
In this case check all loaded pam module binaries (/usr/lib/security/* owner 0:0 mode 755) also.
Offline
Elizabeth wrote:I've checked each file and from what I can see only /etc/nologin is absent.
I would also like to ask what counts as sufficent perms?
Owner 0:0 mode 644.
Elizabeth wrote:Note: I do remember seeing filesystem repairs running when I started up the system that day, could it be that one of the modules got corrupted in the process or was corrupted?
In this case check all loaded pam module binaries (/usr/lib/security/* owner 0:0 mode 755) also.
Checked both of those, everything seems fine.
Offline
Why did you use the syntax "(wheel)" instead of "@wheel" ?
Offline
Why did you use the syntax "(wheel)" instead of "@wheel" ?
Quite frankly: I did this more than year ago when I was setting up my system, and I used the archwiki which uses that syntax. What would be the difference between the two though?
Offline
I'm not an expert on PAM or configuration file syntax.
I only found "@group" examples inside the comments - the Wiki examples contain brackets.
Offline
I'm not an expert on PAM or configuration file syntax.
I only found "@group" examples inside the comments - the Wiki examples contain brackets.
The access.conf man page says to write it with brackets so I don't think it's an issue?
Offline
-thc wrote:I'm not an expert on PAM or configuration file syntax.
I only found "@group" examples inside the comments - the Wiki examples contain brackets.The access.conf man page says to write it with brackets so I don't think it's an issue?
Correction: upon reading more carefully the @netgroupname syntax is intended for negroups.
Offline
MAJOR UPDATE:
After commenting out the line
-:ALL:ALL
In /etc/security/access.conf, I can log in correctly.
This confirms some things:
None of the *.so files are corrupted, or at the least pam_access.so is not corrupted.
The issue is with how pam_access parses the access.conf file, whether that issue lies with me as a user not formatting it correctly, or with the module itself not reading it. Seemingly, the journalctl log shows it scanning the first two (line two and three) lines and not finding a match for my username ([...] login[3414]: pam_access(login:account): user_match=0, "[username]") but finding it on line four ([...] login[3414]: pam_access(login:account): user_match=2, "[username]"), and since line 4 disallows everyone, it doesn't let me log in.
Concluding my analisys of what happened, I still do not know why the access.conf format didnt work suddenly, as it has worked fine for over a year.
I will try updating my system again and seeing if that fixes it, if it does not, I will open attempt to replace the pam_access.so binaries with new ones, (if this a stupid idea please do tell me), and if that doesn't work, I will open a ticket on the pam github page.
Offline
For now I've made a workaround by manually allowing my user and root to log in locally:
+:(wheel):LOCAL
+:(adm):LOCAL
+:[username]:LOCAL
+:root:LOCAL
-:ALL:ALL
This keeps the added security of the last line while allowing me to use the system thankfully. As to what has caused this, I am still trying to figure that out.
Setting nodefgroup as a argument to pam_acess in /etc/pam.d/system-login didn't work, and the logs still report no matches for (wheel) or (adm), despite the fact that running
"groups [username]" and "groups root" returns "wheel adm [username]" and "adm root" respectively.
I will mark the post as solved and potentially open up a new thread dealing with the issue more directly.
Last edited by Elizabeth (2024-11-26 13:08:27)
Offline
i just had/have a similar problem then described here.
i last upgraded (sudo pacman -Syu) my system on 2024-11-26.
following that upgrade i wasnt able to login:
when i enter my password incorrectly login on tty1 prints something similar to "login illegal",
but when i enter the correct password, login prints something similar to "access denied".
i compared files in /etc/ and some other systemd and pam locations in /usr/, with another similar system that i have where i was able to login,
and all files which feels like they should impact the logging process were the same.
making the change that Elizabeth talks about in post #16, made it so that i can now login:
i changed the following (not including the comments in the file):
+:root:LOCAL
-:root:ALL
+:(wheel):LOCAL
-:ALL:ALL
to the following (added 1 line):
+:root:LOCAL
+:USERNAME:LOCAL #TODO find out why this is needed (or not) and what caused "permission denied" when logging in on tty1
-:root:ALL
+:(wheel):LOCAL
-:ALL:ALL
in place of USERNAME i put my system/login username.
Offline
I'd guess you user is part of the wheel group and was allowed through that entry. That is currently broken in pam 1.7.0 This bug in pam 1.7.0 will be fixed in the next release. Maybe you could ask for the patch to included in the arch linux package or build your own.
https://bbs.archlinux.org/viewtopic.php?id=301315
https://github.com/linux-pam/linux-pam/ … b35b793fe2
Last edited by progandy (2024-12-04 19:44:19)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
This bug seems to make it so that all groups that are *supposed* to be in brackets are authenticated as users. I just took out the brackets from my config and then it worked.
$ diff access.conf.old access.conf
129,130c129,130
< +:(wheel):LOCAL
< +:(bus):LOCAL
---
> +:wheel:LOCAL
> +:bus:LOCAL
It could create some problems if there is an account with the same name as the group you are trying to allow access to though. Group name is only checked after usernames.
Offline