fails if user home directory is kerberized and password change is forced

[clhedrick]

Our home directories are on a file system requiring Kerberos to access. Normal login is with sssd.

In the usual case, auth pam_sss checks the user's static password and creates a Kerberos ticket. pam_google is able to read the user's home directory because the user has a Kerberos ticket. Everything works as usual.

But suppose the user forgets their password. We set a temporary password which is expired. pam_sss in auth phase returns new_authtok_reqd, as it is supposed to. Because the login hasn't actually succeeded, there is now no Kerberos ticket for the user.

What is supposed to happen is that pam_sss in the account phase changes the password and creates a Kerberos ticket. However pam_google, in the auth phase get errno 13 (no permission) when trying to read the user's google auth information, and fails the login. This can be fixed in the pam configuration, but doing so requires a pretty much inscrutable config file.

Suggestion: treat errno 13 like file not found, at least as an option. The only way a user would not have permission to their own directory is some weird condition like this.

[ThomasHabets]

This assumes that the behaviour you want is password reset (and other reasons for password expiry) should disable second factor until the password has been changed, right?

I presume that the home directory is on a networked drive, and that you want the secrets file to be there too?

Yes, this sounds like a valid use case, for opt in (not default). Not default (nor included by nullok, probably) because of the "password expiry disables twofactor" aspect.

Let me know if I understood you correctly.

[clhedrick]

yes, that's right.

I hadn't thought of this as a feature, but rather as something to which I don't see a good alternative. But it may actually be a feature. If someone hasn't used the account in long enough that they've forgotten the password, there's a good chance the second factor won't work either.

We would only put people into this state manually, after verifying identity, so it's doesn't seem a significant risk.

[ThomasHabets]

It's a pretty dangerous feature, I think. To treat EACCES as ENOENT means that one can disable two-factor possibly by just DoSing your NFS/AFS/whatever server. Or other failure modes I can't think of now.

The module already has some dangerous options. It should probably get another option called dangerous_options_enabled that needs to be provided to use those.

So yeah: TODO on this issue: add two options: dangerous_options_enabled, and eaccess_ok, and document the options. (or other suggestions)

You're the first to ask for this though, and I personally don't need it. I'll accept pull requests but realistically don't expect to have time to implement it myself in the foreseeable future.

[clhedrick]

I thought about that. EACCES would require a fairly weird situation. If the KDC isn't responding, pam_sss will fail them. The most likely failure modes, whether DDOS or system, would generate ENOENT, e.g. a file system not mounting correctly or server inaccessible.

We may simply remove support for Google authenticator. The problem is that without this patch, users who aren't using it are disabled if we try to force a password change. We're using IPA, so we have support for a Google authenticator token in the KDC. The advantage of this module is that it lets users require a second factor on some systems but not others, while doing it through the KDC affects every use of their credentials.