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

pam: Allow SIGINT (Ctrl+C) while waiting for device press [proof of concept] #315

Closed
wants to merge 1 commit into from

Conversation

mkropat
Copy link

@mkropat mkropat commented Apr 4, 2024

I wrote this code to better understand why it is tricky to come up with a solution to #108

This change is a bad idea as-is. This might work for sudo, since the sudo process blocks SIGINT and this change overrides that temporarily. However:

  1. There is no guarantee the pam-u2f plugin is being invoked by sudo
  2. Even when we are running in sudo, I'm guessing sudo is not expecting a plugin to change the signal handlers, which invites problems

Even if we wanted to do something like this, the change is incomplete since it doesn't handle pam-u2f resource cleanup, and it doesn't handle all the code paths that wait for user action.

This is a bad idea. This *might* work for sudo, since the sudo process
blocks SIGINT and this change overrides that temporarily. However:

a) There is no guarantee the pam-u2f plugin is being invoked by sudo
b) Even when we are running in sudo, I'm guessing sudo is not expecting
   a plugin to change the signal handlers, which invites problems

Even if we wanted to do something like this, the change is incomplete
since no cleanup of the pam-u2f resources is done when a SIGINT happens.
@mkropat
Copy link
Author

mkropat commented Apr 4, 2024

Closing since I'm not actually proposing this particular approach. I wrote it up to leave breadcrumbs based on what I learned.

@mkropat
Copy link
Author

mkropat commented Apr 4, 2024

Perhaps I too strongly implied that this approach is a bad idea.

Even if sudo isn't the only process that uses libpam, maybe there is no other process that would use libpam in conjunction with pam-u2f where it would inherently be a bad idea to allow SIGINT. Phrase another way: if you're blocked for input (u2f device), wouldn't you want to allow SIGINT always, regardless of context?

I leave it to others to work out the details, since, like I said before, I only know enough C programming to be dangerous.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant