Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add config option to call pam_acct_mgmt #691

Open
natchapman opened this issue Feb 21, 2025 · 2 comments
Open

Add config option to call pam_acct_mgmt #691

natchapman opened this issue Feb 21, 2025 · 2 comments
Labels
enhancement New feature or request

Comments

@natchapman
Copy link

Description

I'd like to limit when I'm allowed to unlock my computer using pam_time. Because pam_time only offers an account module type, and hyprlock never calls pam_acct_mgmt(), pam_time can't be checked. Currently I just log out and the login shell uses pam_time, but this isn't ideal since it means closing all my applications.

@natchapman natchapman added the enhancement New feature or request label Feb 21, 2025
@PaideiaDilemma
Copy link
Collaborator

To me it just doesn't make any sense to do account validation as a lock-screen app.
Can't imagine a reasonable situation, where the account is expired or locked for some reason and that should result in a situation where the user is not supposed to be able to unlock their screen.

Also the user is already logged in when they launch hyprlock and therefore their account must be valid.
When someone uses pam_time that essentially means that he can be logged in, but the account is not valid (That seems weird to me. Why isn't pam_time a normal authentication module?).

It would be trivial to write a pam module that disallows authentication based on the current time.

I would also be ok with calling pam_acct_mgmt behind an option in hyprlock, but I think it just wouldn't make a lot of sense and it is similar amount of work to just implement a custom pam_time module.

@natchapman
Copy link
Author

well, from the pam.d man page, an auth module "establishes that the user is who they claim to be" and an account module "is typically used to restrict/permit access to a service". pam_time is clearly the latter.

in general i don't know why you'd want to prevent a user from logging on, but don't want to deny access to the computer if something changes after logon? it's true that it would be odd to deny unlocking for max password age, since hyprlock doesn't have any facility to let the user change their password, but someone who has that enabled and turns account checks on in their hyprlock config presumably either wants that or can turn that off in pam.d.

not opposed to running my own pam_time but it seems more flexible to use the pam features that already exist

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants