From owner-freebsd-bugs@FreeBSD.ORG Wed Jan 18 11:20:06 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF75D16A432 for ; Wed, 18 Jan 2006 11:20:05 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2DE343D5F for ; Wed, 18 Jan 2006 11:20:02 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0IBK2ZX092930 for ; Wed, 18 Jan 2006 11:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0IBK2D9092929; Wed, 18 Jan 2006 11:20:02 GMT (envelope-from gnats) Resent-Date: Wed, 18 Jan 2006 11:20:02 GMT Resent-Message-Id: <200601181120.k0IBK2D9092929@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Oleg Sharoiko Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B60516A41F for ; Wed, 18 Jan 2006 11:13:35 +0000 (GMT) (envelope-from os@brain.cc.rsu.ru) Received: from brain.cc.rsu.ru (brain.cc.rsu.ru [195.208.252.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F68C43F58 for ; Wed, 18 Jan 2006 11:13:34 +0000 (GMT) (envelope-from os@brain.cc.rsu.ru) Received: from brain.cc.rsu.ru (localhost [127.0.0.1]) by brain.cc.rsu.ru (8.13.5/8.13.4) with ESMTP id k0IBDWGg003283; Wed, 18 Jan 2006 14:13:32 +0300 (MSK) (envelope-from os@brain.cc.rsu.ru) Received: (from os@localhost) by brain.cc.rsu.ru (8.13.5/8.13.4/Submit) id k0IBDWdk003282; Wed, 18 Jan 2006 14:13:32 +0300 (MSK) (envelope-from os) Message-Id: <200601181113.k0IBDWdk003282@brain.cc.rsu.ru> Date: Wed, 18 Jan 2006 14:13:32 +0300 (MSK) From: Oleg Sharoiko To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: and@rsu.ru Subject: bin/91954: [patch] Proposed enhancement for pam_krb5: "optional_ccache" X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oleg Sharoiko List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2006 11:20:06 -0000 >Number: 91954 >Category: bin >Synopsis: [patch] Proposed enhancement for pam_krb5: "optional_ccache" >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed Jan 18 11:20:02 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Oleg Sharoiko >Release: FreeBSD 6.0-STABLE i386 >Organization: Computer Center of Rostov State University >Environment: System: FreeBSD brain.cc.rsu.ru 6.0-STABLE FreeBSD 6.0-STABLE #6: Thu Nov 24 13:06:47 MSK 2005 os@brain.cc.rsu.ru:/usr/obj/usr/src/sys/brain.athlon-xp.RELENG_6.2005-11-07 i386 >Description: The patch, included bellow, adds a new option to pam_krb5 "optional_ccache". This option, when specified, modifies behavior of pam_sm_setcred so that - if credentials were already obtained earlier in pam_sm_authenticate, then pam_sm_setcred will store them in credentials cache; - if there are no credentials pam_sm_setcred doesn't return an error. This way, "optional_ccache" implements "save credentials if they exists, but do not fail if they don't" logic. Currently this logic is not available, as there are only two modes of operation: "always save credentials and fail if they were not obtained" and "don't care about credentials completely". Why I think this is needed? Currently if I want to enable kerberos authentication I put into pam.d/svc something similar to auth sufficient pam_krb5.so no_warn try_first_pass require_keytab noroot auth required pam_unix.so no_warn try_first_pass nullok This works fine until there's a network failure. Network failures may lead to long delays in pam_krb5 when kerberos is not available. Sure when this happens it's still possible to login with passwords from master.passwd, but there will be a long delay during login process. This is undesirable situation because when something fails it must be fixed quick and to fix it login/su is usually required. The only way to eliminate this annoying delay which I can think of is to put pam_unix before pam_krb5 like this: auth sufficient pam_unix.so no_warn try_first_pass nullok auth required pam_krb5.so no_warn try_first_pass require_keytab noroot But currently this setup doesn't work because during pam_sm_authenticate phase openpam stops if pam_unix indicate success, but for pam_sm_setcred openpam treats sufficient as optional and doesn't stop on pam_unix in case of success but rather steps to pam_krb5. In case user was authenticated with pam_unix this leads to a call to pam_sm_setcred from pam_krb5 without prior call to its pam_sm_authenticate. Because pam_krb5 obtains credentials in pam_sm_authenticate this makes pam_sm_setcred (and the whole authentication) to fail if no_ccache is not specified. It's possible to workaround this problem by making pam_krb5 sufficient and adding another pam_unix: auth sufficient pam_unix.so no_warn try_first_pass nullok auth sufficient pam_krb5.so no_warn try_first_pass require_keytab noroot auth required pam_unix.so no_warn try_first_pass nullok But I'd say this is a hack, not a solution. This setup is not clear and might lead to misunderstandings. With the change I propose "optional_ccache" can be specified for pam_krb5 and pam_sm_setcred will return PAM_IGNORE if there are no credentials, but will still save ccache if they exist. This allows unix logins to be independent of kerberos logins and eliminates delays in case of kerberos failures. >How-To-Repeat: >Fix: Index: pam_krb5.8 =================================================================== RCS file: /home/ncvs/src/lib/libpam/modules/pam_krb5/pam_krb5.8,v retrieving revision 1.6 diff -u -r1.6 pam_krb5.8 --- pam_krb5.8 24 Nov 2001 23:41:32 -0000 1.6 +++ pam_krb5.8 18 Jan 2006 11:09:25 -0000 @@ -94,6 +94,16 @@ as ftp or pop, where the user would not be able to destroy them. [This is not a recommendation to use the module for those services.] +.It Cm optional_ccache +Do not fail in the situation when the module is asked to save credentials +which were not obtained. This may happen if the authentication module is +not the first in the stack, and a previous +.Dq Li "sufficient" +module successfully authenticated the user. In this case first step of +authentication will not reach this module and credentials won't be +obtained, but during the second step module still may be asked to save +credentials. When this option is set such requests will be silently +ignored. .It Cm ccache Ns = Ns Ar name Use .Ar name Index: pam_krb5.c =================================================================== RCS file: /home/ncvs/src/lib/libpam/modules/pam_krb5/pam_krb5.c,v retrieving revision 1.23 diff -u -r1.23 pam_krb5.c --- pam_krb5.c 7 Jul 2005 14:16:38 -0000 1.23 +++ pam_krb5.c 18 Jan 2006 11:09:25 -0000 @@ -90,6 +90,7 @@ #define PAM_OPT_FORWARDABLE "forwardable" #define PAM_OPT_NO_CCACHE "no_ccache" #define PAM_OPT_REUSE_CCACHE "reuse_ccache" +#define PAM_OPT_OPTIONAL_CCACHE "optional_ccache" /* * authentication management @@ -394,7 +395,10 @@ /* Retrieve the temporary cache */ retval = pam_get_data(pamh, "ccache", &cache_data); if (retval != PAM_SUCCESS) { - retval = PAM_CRED_UNAVAIL; + if (openpam_get_option(pamh, PAM_OPT_OPTIONAL_CCACHE)) + retval = PAM_IGNORE; + else + retval = PAM_CRED_UNAVAIL; goto cleanup3; } krbret = krb5_cc_resolve(pam_context, cache_data, &ccache_temp); >Release-Note: >Audit-Trail: >Unformatted: