The Kerberos provider didn't handle ERR_CHPASS_FAILED at all, which resulted in the default return code (System Error) to be returned if password change failed for pretty much any reason, including password too recent etc.
On (29/10/13 10:08), Jakub Hrozek wrote:
The Kerberos provider didn't handle ERR_CHPASS_FAILED at all, which resulted in the default return code (System Error) to be returned if password change failed for pretty much any reason, including password too recent etc.
From a43544b15e75d1c3c10e842df713ea87f139dfd3 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek jhrozek@redhat.com Date: Tue, 29 Oct 2013 05:05:29 +0100 Subject: [PATCH] KRB5: Handle ERR_CHPASS_FAILED
The Kerberos provider didn't handle ERR_CHPASS_FAILED at all, which resulted in the default return code (System Error) to be returned if password change failed for pretty much any reason, including password too recent etc.
src/providers/krb5/krb5_auth.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/src/providers/krb5/krb5_auth.c b/src/providers/krb5/krb5_auth.c index b4c205789dd2bc6afe0dba911f0303a83b826e92..ce461f5adefc6e42fdc69726ff71d23526375c0c 100644 --- a/src/providers/krb5/krb5_auth.c +++ b/src/providers/krb5/krb5_auth.c @@ -1024,6 +1024,12 @@ static void krb5_auth_done(struct tevent_req *subreq) ret = EOK; goto done;
- case ERR_CHPASS_FAILED:
state->pam_status = PAM_AUTHTOK_ERR;state->dp_err = DP_ERR_OK;ret = EOK;goto done;- default: state->pam_status = PAM_SYSTEM_ERR; state->dp_err = DP_ERR_OK;
-- 1.8.3.1
ACK, works fine.
LS
On Tue, Oct 29, 2013 at 02:33:52PM +0100, Lukas Slebodnik wrote:
On (29/10/13 10:08), Jakub Hrozek wrote:
The Kerberos provider didn't handle ERR_CHPASS_FAILED at all, which resulted in the default return code (System Error) to be returned if password change failed for pretty much any reason, including password too recent etc.
From a43544b15e75d1c3c10e842df713ea87f139dfd3 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek jhrozek@redhat.com Date: Tue, 29 Oct 2013 05:05:29 +0100 Subject: [PATCH] KRB5: Handle ERR_CHPASS_FAILED
The Kerberos provider didn't handle ERR_CHPASS_FAILED at all, which resulted in the default return code (System Error) to be returned if password change failed for pretty much any reason, including password too recent etc.
src/providers/krb5/krb5_auth.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/src/providers/krb5/krb5_auth.c b/src/providers/krb5/krb5_auth.c index b4c205789dd2bc6afe0dba911f0303a83b826e92..ce461f5adefc6e42fdc69726ff71d23526375c0c 100644 --- a/src/providers/krb5/krb5_auth.c +++ b/src/providers/krb5/krb5_auth.c @@ -1024,6 +1024,12 @@ static void krb5_auth_done(struct tevent_req *subreq) ret = EOK; goto done;
- case ERR_CHPASS_FAILED:
state->pam_status = PAM_AUTHTOK_ERR;state->dp_err = DP_ERR_OK;ret = EOK;goto done;- default: state->pam_status = PAM_SYSTEM_ERR; state->dp_err = DP_ERR_OK;
-- 1.8.3.1
ACK, works fine.
LS
Thanks for the review, pushed to master and sssd-1-11
On (29/10/13 10:08), Jakub Hrozek wrote:
The Kerberos provider didn't handle ERR_CHPASS_FAILED at all, which resulted in the default return code (System Error) to be returned if password change failed for pretty much any reason, including password too recent etc.
I found a selinux problem, while I was testing thjis patch.
[check_if_uid_is_active] (0x0020): systemd-login gave error 13: Permission denied
Raw Audit Messages type=AVC msg=audit(1383053470.652:1689): avc: denied { search } for pid=17295 comm="sssd_be" name="users" dev="tmpfs" ino=12761 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:systemd_logind_var_run_t:s0 tclass=dir
type=SYSCALL msg=audit(1383053470.652:1689): arch=x86_64 syscall=open success=no exit=EACCES a0=7f66773043b0 a1=80000 a2=1b6 a3=0 items=0 ppid=17294 pid=17295 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=sssd_be exe=/usr/libexec/sssd/sssd_be subj=system_u:system_r:sssd_t:s0 key=(null)
We use systemd function sd_uid_get_sessions(uid, 0, NULL) from header file systemd/sd-login.h and sssd_be cannot access directory /run/systemd/users/. But we did not directly search this directory. Is it bug in systemd or selinux-policy?
LS
On Tue, Oct 29, 2013 at 02:42:36PM +0100, Lukas Slebodnik wrote:
On (29/10/13 10:08), Jakub Hrozek wrote:
The Kerberos provider didn't handle ERR_CHPASS_FAILED at all, which resulted in the default return code (System Error) to be returned if password change failed for pretty much any reason, including password too recent etc.
I found a selinux problem, while I was testing thjis patch.
[check_if_uid_is_active] (0x0020): systemd-login gave error 13: Permission denied
Raw Audit Messages type=AVC msg=audit(1383053470.652:1689): avc: denied { search } for pid=17295 comm="sssd_be" name="users" dev="tmpfs" ino=12761 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:systemd_logind_var_run_t:s0 tclass=dir
type=SYSCALL msg=audit(1383053470.652:1689): arch=x86_64 syscall=open success=no exit=EACCES a0=7f66773043b0 a1=80000 a2=1b6 a3=0 items=0 ppid=17294 pid=17295 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=sssd_be exe=/usr/libexec/sssd/sssd_be subj=system_u:system_r:sssd_t:s0 key=(null)
We use systemd function sd_uid_get_sessions(uid, 0, NULL) from header file systemd/sd-login.h and sssd_be cannot access directory /run/systemd/users/. But we did not directly search this directory. Is it bug in systemd or selinux-policy?
selinux-policy, can you file a bugzilla?
Also, good catch.
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Lukas Slebodnik