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

Issue: PAM module doesn't allow login with other PAM modules on error #535

Open
adombeck opened this issue Sep 16, 2024 · 5 comments
Open
Assignees
Labels
bug Something isn't working jira pam

Comments

@adombeck
Copy link
Contributor

If any error occors in our PAM module, we print an error message and return an error return code which causes the login to be aborted. For example if the gRPC connection to authd fails:

could not get current available brokers: couldn't connect to authd daemon: error reading from server: EOF
sudo: PAM authentication error: Unknown error -1
sudo: a password is required

This behavior makes it hard for the user to recover from the error, because they can't log in anymore as any user, including root (so su or sudo will fail as well). I think we should instead handle errors by printing an error message and letting PAM try authentication with the next PAM module. If I understand the PAM manual, that can be done by returning PAM_IGNORE.

@adombeck adombeck added the bug Something isn't working label Sep 16, 2024
@3v1n0
Copy link
Collaborator

3v1n0 commented Sep 16, 2024

This was done on purpose as part of #406

The point is that when authd is the selected auth method, then nothing else should be used, unless explicitly requested via the "local" broker. Indeed we can use more complex handing by using something like [authinfo_unavail=ignore] in the case the server is not started for example (or filtering out similar errors), but I'm unsure this is a bug or a configuration issue.

@jcoffi-ghlabs
Copy link

jcoffi-ghlabs commented Sep 17, 2024

Are you trying to ensure that it isn't interoperable with the rest of Linux? I mean, rendering PAM useless instead of working with PAM feels like something Microsoft or Apple would do. "If you use our stuff, you can't use anything else."

@3v1n0
Copy link
Collaborator

3v1n0 commented Sep 17, 2024

You can use other stuff indeed, but we don't officially support such configurations (yet).

@didrocks
Copy link
Member

I think @3v1n0 is slightely incorrect here. If we are failing for authentication failure, yes, we should abort. However, for other use cases like authd daemon not being reachable, I think it’s ok to skip us. What we don’t want is:

  • you start some authentication with authd and don’t select the "Local" but a given broker
  • if the broker can’t authenticate you, you are then asked for a local password (rest of the PAM stack) which surely doesn’t exists.

So, we should probably add [authinfo_unavail=ignore] and ensure this is our returned value from our PAM like in case we can’t connect to authd (in addition to writing the error though, so that people don’t think the ¨password" is for the created local password with authd)

@3v1n0
Copy link
Collaborator

3v1n0 commented Sep 17, 2024

So, we should probably add [authinfo_unavail=ignore] and ensure this is our returned value from our PAM like in case we can’t connect to authd (in addition to writing the error though, so that people don’t think the ¨password" is for the created local password with authd)

Ok, that's easy enough then since we already do return pam.AuthInfoUnavail when not connected to the server, as initially I thought we would have ignored such case, but then it looked to me we wanted to be sure that if the authd daemon and modules are installed, then they should be used.

But it's also true that one could disable the systemd service or socket without having to break PAM.

@3v1n0 3v1n0 self-assigned this Sep 17, 2024
@adombeck adombeck added the jira label Sep 20, 2024
@3v1n0 3v1n0 added the pam label Nov 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working jira pam
Projects
None yet
Development

No branches or pull requests

4 participants