Bug 563442
Summary: | user disallowed by .k5login file | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Marcus Moeller <marcus.moeller> |
Component: | pam_krb5 | Assignee: | Nalin Dahyabhai <nalin> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 12 | CC: | andrew, nalin |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | pam_krb5-2.3.7-3.fc12 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-03-24 23:28:48 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Marcus Moeller
2010-02-10 08:50:18 UTC
user ccache file is not created during login. Generally speaking, this won't work -- pam_krb5 (reassigning to that component) assumes the user's ID to read .k5login, mainly to avoid problems with NFS root squashing. At that point, without a usable credential cache around (it's still doing an authorization check here, so it hasn't created one yet), it loses the ability to look up the location of the user's home directory and krb5_kuserok() returns a failure. The module could probably add an option to create a temporary ccache that would be accessible to the user for the duration of the krb5_kuserok() call. I'm on the fence about whether or not it should be a default setting, because even though it'll be slower, I can see it being needed for users with NFS home directories which are accessed using RPCSEC_GSS. Hi Nalin, I have already tried to create a home directory for that user in advance, even with a .k5login file. I am not sure if the main problem is that no credential file is created at all, as if I create one for this specific user from root account, login is possible. Also please note, that exactly the same setup worked fine on RHEL 5 (In reply to comment #3) > Hi Nalin, > > I have already tried to create a home directory for that user in advance, even > with a .k5login file. I am not sure if the main problem is that no credential > file is created at all, as if I create one for this specific user from root > account, login is possible. If supplied with credentials for the user, when pam_krb5 drops privileges, it'd still able to look up the location of the user's home directory, so .k5login could allow or deny access (note that by default, if a .k5login file exists, the user's principal name has to be listed in it in order for access to be allowed -- it's not implicit). If the lookup fails, krb5_kuserok() unconditionally returns a failure, and pam_krb5 interprets that as an indication that access should be denied. > Also please note, that exactly the same setup worked fine on RHEL 5 The version of pam_krb5 in RHEL5 doesn't switch to the user's privileges (that was added around 2.2.22), so credentials for the root user would have been accessible, and I expect that this case would have succeeded. > If supplied with credentials for the user, when pam_krb5 drops privileges, it'd
> still able to look up the location of the user's home directory, so .k5login
> could allow or deny access (note that by default, if a .k5login file exists,
> the user's principal name has to be listed in it in order for access to be
> allowed -- it's not implicit). If the lookup fails, krb5_kuserok()
> unconditionally returns a failure, and pam_krb5 interprets that as an
> indication that access should be denied.
Hmm, strange. The user home is queried via LDAP and located at /nas/$USER. I have created this directory and added a .k5login file with the content you mentioned. The error message still occurs.
And what about if the home dir does not exist yet (e.g. should be created with pam_mkhomedir)?
Is there perhaps a way to debug the procedure?
Best Regards
Marcus
(In reply to comment #5) > > If supplied with credentials for the user, when pam_krb5 drops privileges, it'd > > still able to look up the location of the user's home directory, so .k5login > > could allow or deny access (note that by default, if a .k5login file exists, > > the user's principal name has to be listed in it in order for access to be > > allowed -- it's not implicit). If the lookup fails, krb5_kuserok() > > unconditionally returns a failure, and pam_krb5 interprets that as an > > indication that access should be denied. > > Hmm, strange. The user home is queried via LDAP and located at /nas/$USER. I > have created this directory and added a .k5login file with the content you > mentioned. The error message still occurs. Is there a credential cache available for the user when you do this? I believe the key difference is whether or not a process running as the user has access to the credential cache, which it will need in order to contact the directory server to look up information about the user. When that fails, the code won't even be able to check if the directory exists; it'll just give up. > And what about if the home dir does not exist yet (e.g. should be created with > pam_mkhomedir)? > > Is there perhaps a way to debug the procedure? Passively, it's either debug statements in pam_krb5 or nss_ldap (whether or not there's a cred cache available, what UID the process is running under at that moment). Otherwise, you'd have to attach to the process with a debugger (I tend to use 'login' for this sort of thing -- either at the console or via 'telnet localhost' -- as it doesn't have to spend time dealing with windowing systems or the privilege separation logic that sshd does). > Is there a credential cache available for the user when you do this? I believe
> the key difference is whether or not a process running as the user has access
> to the credential cache, which it will need in order to contact the directory
> server to look up information about the user. When that fails, the code won't
> even be able to check if the directory exists; it'll just give up.
LDAP is set up to use GSSAPI/SASL. A ticket for the nnslap user is received via cron from root account (using keytab) and stored in /tmp/krb5cc_0.
getent works fine as root.
username lookup also works (from what ldap debug says) but the users cc is not created during login so the rest fails.
Best Regards
Marcus
Little update: Had to add: krb5_ccname FILE:/tmp/krb5cc_0 to ldap.conf (thought this was default) and chmod 644 /tmp/krb5cc_0 What still exists is that SELinux prevents access to this file. Is there perhaps a special file context that could be used, and/or could the policy be updated? Best Regards Marcus pam_krb5-2.3.11-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/pam_krb5-2.3.11-1.fc13 pam_krb5-2.3.7-3.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/pam_krb5-2.3.7-3.fc12 Marcus, can you check if the packages listed in comment #10 fix the problem on your system? pam_krb5-2.3.7-3.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update pam_krb5'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/pam_krb5-2.3.7-3.fc12 pam_krb5-2.3.11-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. pam_krb5-2.3.7-3.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. This issue is still a serious problem for RHEL 5 systems. Will there be a backport of the fix to this release? |