From wyllys@sac.sfbay.sun.com Thu Jan 15 08:42:20 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0FGgJ9n020753 for ; Thu, 15 Jan 2009 08:42:19 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n0FGg0Z8010626; Fri, 16 Jan 2009 00:42:18 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDI00C0JUEHBO00@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 08:42:17 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDI005GTUEGP690@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 08:42:17 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0FGgGQW018564; Thu, 15 Jan 2009 08:42:16 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0FGgFv6020747; Thu, 15 Jan 2009 08:42:15 -0800 (PST) Received: (from wyllys@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n0FGgFwN020743; Thu, 15 Jan 2009 08:42:15 -0800 (PST) Date: Thu, 15 Jan 2009 08:42:15 -0800 (PST) From: Wyllys Ingersoll Subject: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] To: PSARC-ext@sun.com Cc: kerberos-interest@sun.com Message-id: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 5647 Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Kerberos CCAPI 1.2. Name of Document Author/Supplier: Author: Shawn Emery 1.3 Date of This Document: 15 January, 2009 4. Technical Description Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: CCAPI 1.2. Name of Document Author/Supplier: Author: Shawn M. Emery 1.3 Date of This Document: 5 January, 2009 4. Technical Description 1. Introduction Project will create a new credential cache type that will allow a per session Kerberos credential cache. The CCAPI cache type will not be the default credential cache type for normal initial authentication, it will remain "FILE". Per session ccaches is highly desirable for a number of reasons, but for this particular project it is required that credentials used for long running proccesses not interfere/overwrite credentials that are created from normal operations such as initial authentication or delegation. 2. Overview - introduce CCAPI to the krb5 mech library - support for per session ccache - daemon for ccache in memory accross processes - door fs for IPC between user processes and daemon - get peer cred useful for authentication - gssd revamp - per user gssd - doors fs will be new form of messaging from kernel space - get peer cred useful for authentication - use new CCAPI 3. Daemon New per user daemon is proposed, ccd (credential cache daemon). ccd(1M) contains various credential cache stores for the user. Particular ccache stores in the daemon are referenced by the tuple (uid, session id). The uid and session-id are ascii string characters. session id can be configurable through libraries and environment variable. 4. krb5 mech The daemon is invoked through the mech_krb5 user library. The idea is to minimally affect the invoking process when the first and only ccd process is instantiated for the user. The associated door file will remain open after the mech has returned. This will provide a way of determining prior startup of the ccd process. 5. IPC Preferred form of IPC is doors, even though MIT implementation in Unix is domain sockets. With doors we can perform credentialling with native functions, e.g. door_ucred(3C). An attempt will be made to make the IPC code as portable as possible. 6. Interface table Release Binding micro/patch ccd Consolidation private and created by this project. New krb5_envvar(5) ccache type Unstable New krb5.conf(4) ccache type stanza Evolving 7. Related CR/PSARCs 6210470 No provision for delayed execution (cron/at) for services requiring Kerberos credentials 6618410 want pam module to authenticate by kerberos keytab 8. Manual page differences krb5envvar.5: @@ -43,11 +43,11 @@ Used by the mechanism to specify the location of the credential cache. The variable can be set to the follow- ing value: - [[:]] + [[:]] where can be FILE or MEMORY. is the location of the principal's credential cache. If KRB5CCNAME is not defined, the default value is: @@ -75,10 +75,16 @@ The MEMORY credential cache type is used only in special cases, such as when making a temporary cache for the life of the invoking process. + The API credential cache type is a memory credential cache + store shared between a user's processes. This cache is + helpful in storing per session credentials caches. This + allows for the ability to have multiple default credentials + that are autonomous. + KRB5RCNAME Used by the mechanism to specify the type and location of the replay cache. The variable can be set to the fol- lowing value: krb5.conf.4: @@ -230,10 +230,16 @@ vulnerable to DNS spoofing attacks. This parameter can be in the [realms] section to set it on a per-realm basis, or it can be in the [libdefaults] section to make it a network-wide setting for all realms. + ccache_type + + Contains the credential cache type used by the system. Valid values + are "file" or "ccapi". If unspecified then the default type is "file". + Refer to krb5envvar(5) under KRB5CCNAME for a description of each type. + [appdefaults] This section contains subsections for Kerberos V5 applica- tions, where relation-subsection is the name of an applica- tion. Each subsection contains relations that define the default behaviors for that application. 9. JGSS JGSS will continue to only support "FILE" credential cache types at this time. 10. Resources and Schedule 10.4. Steering Committee requested information 10.4.1. Consolidation C-team Name: ON 10.5. ARC review type: FastTrack 10.6. ARC Exposure: open 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Glenn.Faden@sun.com Thu Jan 15 11:04:47 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0FJ4kiX024874 for ; Thu, 15 Jan 2009 11:04:46 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0FJ4akD028827; Thu, 15 Jan 2009 19:04:45 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDJ00L150ZW2P00@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 11:04:44 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ00HEC0ZVQT70@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 11:04:43 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0FJ4h2a027883; Thu, 15 Jan 2009 11:04:43 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDJ00H010PA1V00@fe-sfbay-09.sun.com> (original mail from Glenn.Faden@Sun.COM); Thu, 15 Jan 2009 11:04:43 -0800 (PST) Received: from rampartgf.local ([129.150.17.142]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ006Y50ZO18D0@fe-sfbay-09.sun.com>; Thu, 15 Jan 2009 11:04:36 -0800 (PST) Date: Thu, 15 Jan 2009 11:04:36 -0800 From: Glenn Faden Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> Sender: Glenn.Faden@sun.com To: Wyllys Ingersoll Cc: PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <496F88C4.9060605@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 1228 Wyllys Ingersoll wrote: > Template Version: @(#)sac_nextcase %I% %G% SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Kerberos CCAPI > 1.2. Name of Document Author/Supplier: > Author: Shawn Emery > 1.3 Date of This Document: > 15 January, 2009 > 4. Technical Description > Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > CCAPI > 1.2. Name of Document Author/Supplier: > Author: Shawn M. Emery > 1.3 Date of This Document: > 5 January, 2009 > 4. Technical Description > > > 5. IPC > > Preferred form of IPC is doors, even though MIT implementation in > Unix is domain sockets. With doors we can perform credentialling with > native functions, e.g. door_ucred(3C). > > An attempt will be made to make the IPC code as portable as possible. > FYI, you can also get the ucred from a UNIX domain socket, via getpeerucred(). Also, UNIX domain sockets and doors are not both supported for cross zone access as long as the server is in the global zone. So doors are not required. From Shawn.Emery@sun.com Thu Jan 15 11:14:00 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0FJE0Jl025143 for ; Thu, 15 Jan 2009 11:14:00 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0FJDrVx037920; Thu, 15 Jan 2009 12:13:59 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDJ0054V1F9BK10@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 11:13:57 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ00KUZ1DBR140@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 11:12:47 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0FJClAD004243; Thu, 15 Jan 2009 19:12:47 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDJ00D010Q0K400@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM); Thu, 15 Jan 2009 12:12:47 -0700 (MST) Received: from shawn-emerys-computer.local ([129.150.34.148]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ004651D3B9C0@mail-amer.sun.com>; Thu, 15 Jan 2009 12:12:39 -0700 (MST) Date: Thu, 15 Jan 2009 12:13:10 -0700 From: "Shawn M. Emery" Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <496F88C4.9060605@sun.com> Sender: Shawn.Emery@sun.com To: Glenn Faden Cc: Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <496F8AC6.1000008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <496F88C4.9060605@sun.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 1460 Glenn Faden wrote: > Wyllys Ingersoll wrote: >> Template Version: @(#)sac_nextcase %I% %G% SMI >> This information is Copyright 2009 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Kerberos CCAPI >> 1.2. Name of Document Author/Supplier: >> Author: Shawn Emery >> 1.3 Date of This Document: >> 15 January, 2009 >> 4. Technical Description >> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI >> This information is Copyright 2009 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> CCAPI >> 1.2. Name of Document Author/Supplier: >> Author: Shawn M. Emery >> 1.3 Date of This Document: >> 5 January, 2009 >> 4. Technical Description >> >> >> 5. IPC >> >> Preferred form of IPC is doors, even though MIT >> implementation in >> Unix is domain sockets. With doors we can perform >> credentialling with >> native functions, e.g. door_ucred(3C). >> >> An attempt will be made to make the IPC code as portable as >> possible. >> > FYI, you can also get the ucred from a UNIX domain socket, via > getpeerucred(). Also, UNIX domain sockets and doors are not both > supported for cross zone access as long as the server is in the global > zone. So doors are not required. I also want to combine functionality of the CCacheServer and gssd. So is there an up-call mechanism for domain sockets as well? Shawn. -- From Glenn.Faden@sun.com Thu Jan 15 11:19:05 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0FJJ4KV025227 for ; Thu, 15 Jan 2009 11:19:04 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n0FJGq5C008938; Fri, 16 Jan 2009 03:19:02 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDJ00L0B1NOSR00@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 11:19:00 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ00HVS1NMQSA0@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 11:18:59 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0FJIwHb029707; Thu, 15 Jan 2009 11:18:58 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDJ00H011AF4F00@fe-sfbay-09.sun.com> (original mail from Glenn.Faden@Sun.COM); Thu, 15 Jan 2009 11:18:58 -0800 (PST) Received: from rampartgf.local ([129.150.17.142]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ00JA81NHIO40@fe-sfbay-09.sun.com>; Thu, 15 Jan 2009 11:18:54 -0800 (PST) Date: Thu, 15 Jan 2009 11:18:52 -0800 From: Glenn Faden Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <496F8AC6.1000008@sun.com> Sender: Glenn.Faden@sun.com To: "Shawn M. Emery" Cc: Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <496F8C1C.4040407@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <496F88C4.9060605@sun.com> <496F8AC6.1000008@sun.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 1566 Shawn M. Emery wrote: > Glenn Faden wrote: >> Wyllys Ingersoll wrote: >>> Template Version: @(#)sac_nextcase %I% %G% SMI >>> This information is Copyright 2009 Sun Microsystems >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> Kerberos CCAPI >>> 1.2. Name of Document Author/Supplier: >>> Author: Shawn Emery >>> 1.3 Date of This Document: >>> 15 January, 2009 >>> 4. Technical Description >>> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI >>> This information is Copyright 2009 Sun Microsystems >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> CCAPI >>> 1.2. Name of Document Author/Supplier: >>> Author: Shawn M. Emery >>> 1.3 Date of This Document: >>> 5 January, 2009 >>> 4. Technical Description >>> >>> >>> 5. IPC >>> >>> Preferred form of IPC is doors, even though MIT >>> implementation in >>> Unix is domain sockets. With doors we can perform >>> credentialling with >>> native functions, e.g. door_ucred(3C). >>> >>> An attempt will be made to make the IPC code as portable as >>> possible. >>> >> FYI, you can also get the ucred from a UNIX domain socket, via >> getpeerucred(). Also, UNIX domain sockets and doors are not both >> supported for cross zone access as long as the server is in the >> global zone. So doors are not required. > > I also want to combine functionality of the CCacheServer and gssd. So > is there an up-call mechanism for domain sockets as well? No, for up-calls you need to use doors. --Glenn From Nicolas.Williams@sun.com Thu Jan 15 13:06:34 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0FL6Yo8016193 for ; Thu, 15 Jan 2009 13:06:34 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0FL6RW8012739; Thu, 15 Jan 2009 21:06:30 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDJ008056MTM200@brm-avmta-1.central.sun.com>; Thu, 15 Jan 2009 14:06:29 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ003WL6MS0R40@brm-avmta-1.central.sun.com>; Thu, 15 Jan 2009 14:06:29 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0FL5LQC016545; Thu, 15 Jan 2009 15:05:21 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0FL5L9A016544; Thu, 15 Jan 2009 15:05:21 -0600 (CST) Date: Thu, 15 Jan 2009 15:05:21 -0600 From: Nicolas Williams Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <496F8C1C.4040407@sun.com> To: Glenn Faden Cc: "Shawn M. Emery" , Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <20090115210520.GR884@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <496F88C4.9060605@sun.com> <496F8AC6.1000008@sun.com> <496F8C1C.4040407@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 507 On Thu, Jan 15, 2009 at 11:18:52AM -0800, Glenn Faden wrote: > Shawn M. Emery wrote: > >I also want to combine functionality of the CCacheServer and gssd. So > >is there an up-call mechanism for domain sockets as well? > > No, for up-calls you need to use doors. kgssapi->gssd currently uses RPC over loopback -- not far from Unix domain sockets. So it may be doable, but still, it'd be much better to contribute some #ifdef solaris code to MIT than use any IPC other than doors for upcalls. Nico -- From Shawn.Emery@Sun.COM Thu Jan 15 13:14:27 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0FLERnH016461 for ; Thu, 15 Jan 2009 13:14:27 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0FLEP1k016829; Thu, 15 Jan 2009 13:14:26 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDJ0060D7010K00@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 13:14:25 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ0010O700UQ40@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 13:14:24 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0FLEOJh001305; Thu, 15 Jan 2009 21:14:24 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDJ00D015SIGH00@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM); Thu, 15 Jan 2009 14:14:24 -0700 (MST) Received: from shawn-emerys-computer.local ([129.150.34.148]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ002YI6ZZ1RC0@mail-amer.sun.com>; Thu, 15 Jan 2009 14:14:23 -0700 (MST) Date: Thu, 15 Jan 2009 14:14:54 -0700 From: "Shawn M. Emery" Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <20090115210520.GR884@Sun.COM> Sender: Shawn.Emery@Sun.COM To: Nicolas Williams Cc: Glenn Faden , Wyllys Ingersoll , PSARC-ext@Sun.COM, kerberos-interest@Sun.COM Message-id: <496FA74E.2030204@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <496F88C4.9060605@sun.com> <496F8AC6.1000008@sun.com> <496F8C1C.4040407@sun.com> <20090115210520.GR884@Sun.COM> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 716 Nicolas Williams wrote: > On Thu, Jan 15, 2009 at 11:18:52AM -0800, Glenn Faden wrote: > >> Shawn M. Emery wrote: >> >>> I also want to combine functionality of the CCacheServer and gssd. So >>> is there an up-call mechanism for domain sockets as well? >>> >> No, for up-calls you need to use doors. >> > > kgssapi->gssd currently uses RPC over loopback -- not far from Unix > domain sockets. So it may be doable, but still, it'd be much better to > contribute some #ifdef solaris code to MIT than use any IPC other than > doors for upcalls. > In a separate e-mail thread with them, I had suggested a plugin design, but did not commit to this as a requirement for the project. Shawn. -- From Nicolas.Williams@sun.com Thu Jan 15 13:31:36 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0FLVZjN016686 for ; Thu, 15 Jan 2009 13:31:36 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n0FLVNu2016485; Fri, 16 Jan 2009 05:31:30 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDJ003177SHK000@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 13:31:29 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ00KVA7SFQZD0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 13:31:28 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0FLUKa9016750; Thu, 15 Jan 2009 15:30:20 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0FLUKLS016749; Thu, 15 Jan 2009 15:30:20 -0600 (CST) Date: Thu, 15 Jan 2009 15:30:20 -0600 From: Nicolas Williams Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <496FA74E.2030204@sun.com> To: "Shawn M. Emery" Cc: Glenn Faden , Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <20090115213020.GT884@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <496F88C4.9060605@sun.com> <496F8AC6.1000008@sun.com> <496F8C1C.4040407@sun.com> <20090115210520.GR884@Sun.COM> <496FA74E.2030204@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 955 On Thu, Jan 15, 2009 at 02:14:54PM -0700, Shawn M. Emery wrote: > Nicolas Williams wrote: > >On Thu, Jan 15, 2009 at 11:18:52AM -0800, Glenn Faden wrote: > > > >>Shawn M. Emery wrote: > >> > >>>I also want to combine functionality of the CCacheServer and gssd. So > >>>is there an up-call mechanism for domain sockets as well? > >>> > >>No, for up-calls you need to use doors. > >> > > > >kgssapi->gssd currently uses RPC over loopback -- not far from Unix > >domain sockets. So it may be doable, but still, it'd be much better to > >contribute some #ifdef solaris code to MIT than use any IPC other than > >doors for upcalls. > > > > In a separate e-mail thread with them, I had suggested a plugin design, > but did not commit to this as a requirement for the project. I don't think a plugin is needed here. The particular flavor of IPC to use is not something one should decide on a whim and configure -- it's very OS-specific. From Shawn.Emery@sun.com Thu Jan 15 13:56:49 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0FLumLr017458 for ; Thu, 15 Jan 2009 13:56:49 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0FLuVVt010970; Thu, 15 Jan 2009 21:56:47 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDJ006078YKYC00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 13:56:44 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ006278YJ7710@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 13:56:44 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0FLuhnG029697; Thu, 15 Jan 2009 21:56:43 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDJ008018UM7200@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM); Thu, 15 Jan 2009 14:56:43 -0700 (MST) Received: from shawn-emerys-computer.local ([129.150.34.148]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ002AI8YIH5A0@mail-amer.sun.com>; Thu, 15 Jan 2009 14:56:42 -0700 (MST) Date: Thu, 15 Jan 2009 14:57:13 -0700 From: "Shawn M. Emery" Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <20090115213020.GT884@Sun.COM> Sender: Shawn.Emery@sun.com To: Nicolas Williams Cc: Glenn Faden , Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <496FB139.9020404@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <496F88C4.9060605@sun.com> <496F8AC6.1000008@sun.com> <496F8C1C.4040407@sun.com> <20090115210520.GR884@Sun.COM> <496FA74E.2030204@sun.com> <20090115213020.GT884@Sun.COM> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 1379 Nicolas Williams wrote: > On Thu, Jan 15, 2009 at 02:14:54PM -0700, Shawn M. Emery wrote: > >> Nicolas Williams wrote: >> >>> On Thu, Jan 15, 2009 at 11:18:52AM -0800, Glenn Faden wrote: >>> >>> >>>> Shawn M. Emery wrote: >>>> >>>> >>>>> I also want to combine functionality of the CCacheServer and gssd. So >>>>> is there an up-call mechanism for domain sockets as well? >>>>> >>>>> >>>> No, for up-calls you need to use doors. >>>> >>>> >>> kgssapi->gssd currently uses RPC over loopback -- not far from Unix >>> domain sockets. So it may be doable, but still, it'd be much better to >>> contribute some #ifdef solaris code to MIT than use any IPC other than >>> doors for upcalls. >>> >>> >> In a separate e-mail thread with them, I had suggested a plugin design, >> but did not commit to this as a requirement for the project. >> > > I don't think a plugin is needed here. The particular flavor of IPC to > use is not something one should decide on a whim and configure -- it's > very OS-specific. > Two are being considered for OpenSolaris, so within each OS there could be options or accross multiple OS's. In any case, I am loath to mix-and-match IPCs across kernel and user space as we prevent code reuse and the inherit benefits that it provides (simplicity, risk, etc.). Shawn. -- From Nicolas.Williams@Sun.COM Thu Jan 15 14:01:05 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0FM14lM017601 for ; Thu, 15 Jan 2009 14:01:05 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0FM126Y058717; Thu, 15 Jan 2009 15:01:04 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDJ0070R95QIB00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 14:01:02 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ0068Y95P7830@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 14:01:01 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0FLxsus016977; Thu, 15 Jan 2009 15:59:54 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0FLxsio016976; Thu, 15 Jan 2009 15:59:54 -0600 (CST) Date: Thu, 15 Jan 2009 15:59:54 -0600 From: Nicolas Williams Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <496FB139.9020404@sun.com> To: "Shawn M. Emery" Cc: Glenn Faden , Wyllys Ingersoll , PSARC-ext@Sun.COM, kerberos-interest@Sun.COM Message-id: <20090115215953.GX884@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <496F88C4.9060605@sun.com> <496F8AC6.1000008@sun.com> <496F8C1C.4040407@sun.com> <20090115210520.GR884@Sun.COM> <496FA74E.2030204@sun.com> <20090115213020.GT884@Sun.COM> <496FB139.9020404@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 591 On Thu, Jan 15, 2009 at 02:57:13PM -0700, Shawn M. Emery wrote: > Two are being considered for OpenSolaris, so within each OS there could Why? For interop with MIT krb5 user-land built by users? If MIT krb5 received contributions from us that #ifdef solaris the choice of IPC then this problem goes away. > be options or accross multiple OS's. In any case, I am loath to I don't understand this. > mix-and-match IPCs across kernel and user space as we prevent code reuse > and the inherit benefits that it provides (simplicity, risk, etc.). Yes, me too. So why must we have two? From Nicolas.Williams@Sun.COM Thu Jan 15 14:02:59 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0FM2xBY017641 for ; Thu, 15 Jan 2009 14:02:59 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0FM2wXc011973; Thu, 15 Jan 2009 14:02:58 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDJ0090998X1U00@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 14:02:57 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ001U898VUV70@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 14:02:55 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0FM1mVp016996; Thu, 15 Jan 2009 16:01:48 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0FM1m3N016995; Thu, 15 Jan 2009 16:01:48 -0600 (CST) Date: Thu, 15 Jan 2009 16:01:48 -0600 From: Nicolas Williams Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <20090115215953.GX884@Sun.COM> To: "Shawn M. Emery" Cc: Glenn Faden , Wyllys Ingersoll , PSARC-ext@Sun.COM, kerberos-interest@Sun.COM Message-id: <20090115220148.GB895@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <496F88C4.9060605@sun.com> <496F8AC6.1000008@sun.com> <496F8C1C.4040407@sun.com> <20090115210520.GR884@Sun.COM> <496FA74E.2030204@sun.com> <20090115213020.GT884@Sun.COM> <496FB139.9020404@sun.com> <20090115215953.GX884@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 626 On Thu, Jan 15, 2009 at 03:59:53PM -0600, Nicolas Williams wrote: > > be options or accross multiple OS's. In any case, I am loath to > > mix-and-match IPCs across kernel and user space as we prevent code reuse > > and the inherit benefits that it provides (simplicity, risk, etc.). > > Yes, me too. So why must we have two? I should add that I don't think it'd be a good idea to add any more non-doors upcall IPCs. That it has been done and could be done again is not relevant. We use doors for lots of upcalls and it works real well; adding more upcall mechanisms will complicate the kernel unnecessarily. Nico -- From Shawn.Emery@Sun.COM Thu Jan 15 14:11:29 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0FMBSaS017683 for ; Thu, 15 Jan 2009 14:11:29 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0FMBR5C004676; Thu, 15 Jan 2009 14:11:28 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDJ0080J9N4TQ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 14:11:28 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ006DI9N37740@nwk-avmta-1.sfbay.Sun.COM>; Thu, 15 Jan 2009 14:11:27 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0FMBRnE021027; Thu, 15 Jan 2009 22:11:27 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDJ00L018VSF800@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM); Thu, 15 Jan 2009 15:11:27 -0700 (MST) Received: from shawn-emerys-computer.local ([129.150.34.148]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ0057E9MRMQC0@mail-amer.sun.com>; Thu, 15 Jan 2009 15:11:15 -0700 (MST) Date: Thu, 15 Jan 2009 15:11:46 -0700 From: "Shawn M. Emery" Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <20090115215953.GX884@Sun.COM> Sender: Shawn.Emery@Sun.COM To: Nicolas Williams Cc: Glenn Faden , Wyllys Ingersoll , PSARC-ext@Sun.COM, kerberos-interest@Sun.COM Message-id: <496FB4A2.5040007@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <496F88C4.9060605@sun.com> <496F8AC6.1000008@sun.com> <496F8C1C.4040407@sun.com> <20090115210520.GR884@Sun.COM> <496FA74E.2030204@sun.com> <20090115213020.GT884@Sun.COM> <496FB139.9020404@sun.com> <20090115215953.GX884@Sun.COM> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 968 Nicolas Williams wrote: > On Thu, Jan 15, 2009 at 02:57:13PM -0700, Shawn M. Emery wrote: > >> Two are being considered for OpenSolaris, so within each OS there could >> > > Why? For interop with MIT krb5 user-land built by users? If MIT krb5 > received contributions from us that #ifdef solaris the choice of IPC > then this problem goes away. > I was considering an all or nothing approach, rather than using different IPC for kernel/user space. >> be options or accross multiple OS's. In any case, I am loath to >> > > I don't understand this. > See below. >> mix-and-match IPCs across kernel and user space as we prevent code reuse >> and the inherit benefits that it provides (simplicity, risk, etc.). >> > > Yes, me too. So why must we have two? > I was really wanting to change the gssd IPC and thought doors was a good mechanism for handling this. What are your arguments for not using doors in this case? Shawn. -- From Nicolas.Williams@sun.com Thu Jan 15 14:27:32 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0FMRVHR018369 for ; Thu, 15 Jan 2009 14:27:32 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0FMRIH7027909; Thu, 15 Jan 2009 22:27:30 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDJ00G0BADUPT00@brm-avmta-1.central.sun.com>; Thu, 15 Jan 2009 15:27:30 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ003KEADT0W90@brm-avmta-1.central.sun.com>; Thu, 15 Jan 2009 15:27:29 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0FMQKTe017192; Thu, 15 Jan 2009 16:26:20 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0FMQK4E017191; Thu, 15 Jan 2009 16:26:20 -0600 (CST) Date: Thu, 15 Jan 2009 16:26:20 -0600 From: Nicolas Williams Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> To: Wyllys Ingersoll Cc: PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <20090115222620.GA884@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2830 On Thu, Jan 15, 2009 at 08:42:15AM -0800, Wyllys Ingersoll wrote: > 1. Introduction > > Project will create a new credential cache type that will allow a per > session Kerberos credential cache. The CCAPI cache type will not be > the default credential cache type for normal initial authentication, > it will remain "FILE". > > Per session ccaches is highly desirable for a number of reasons, but > for this particular project it is required that credentials used for > long running proccesses not interfere/overwrite credentials that are > created from normal operations such as initial authentication or > delegation. Given the way gssd works (even if revamped to be per-user gssd instances), to me per-session ccache means adding a kernel-land mechanism for associating user processes with "sessions." If such a mechanism is missing then this case seems incomplete. One possibility is that gssd (or each per-user gssd) will try all of the per-session CCAPI daemons, as opposed to trying to find the CCAPI daemon associated with the process that triggered the upcall to gssd. Either way, there's something missing here. > 3. Daemon > > New per user daemon is proposed, ccd (credential cache daemon). ccd(1M) > contains various credential cache stores for the user. Particular > ccache stores in the daemon are referenced by the tuple > (uid, session id). The uid and session-id are ascii string characters. > session id can be configurable through libraries and environment > variable. Where are the door handles for CCAPI daemons fattach()ed? How are these daemons started? For example, gssd using doors should be started by svc.startd, not inetd. So there's at least one architectural change that probably needs to be described (but maybe not -- is the restarter for a service an architectural detail?). How are the CCAPI daemons started? Are they started by pam_krb5(5)? By kinit(1)? By an IPC call from either pam_krb5(5) or kinit(1) to a master CCAPI daemon started by SMF? And how are these daemons reaped? For login sessions [where pam_krb5 is involved[ I'd expect that pam_krb5:pam_sm_close_session() takes care of it. But if new CCAPI daemon processes can be started by kinit, then how are they destroyed? > 5. IPC > > Preferred form of IPC is doors, even though MIT implementation in > Unix is domain sockets. With doors we can perform credentialling with > native functions, e.g. door_ucred(3C). > > An attempt will be made to make the IPC code as portable as possible. Are people using MIT krb5 CCAPI on Solaris today? If so, that's an argument for keeping the Unix domain socket IPC. Otherwise I'd argue that you need to have only doors IPC. Nico -- From Nicolas.Williams@sun.com Thu Jan 15 14:29:41 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0FMTekU018482 for ; Thu, 15 Jan 2009 14:29:41 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0FMTaUm028880; Thu, 15 Jan 2009 22:29:36 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDJ00A01AHCMS00@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 14:29:36 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ001N8AHBUN90@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 14:29:35 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0FMSQ8n017210; Thu, 15 Jan 2009 16:28:26 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0FMSQ7n017209; Thu, 15 Jan 2009 16:28:26 -0600 (CST) Date: Thu, 15 Jan 2009 16:28:26 -0600 From: Nicolas Williams Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <496FB4A2.5040007@sun.com> To: "Shawn M. Emery" Cc: Glenn Faden , Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <20090115222825.GB884@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <496F88C4.9060605@sun.com> <496F8AC6.1000008@sun.com> <496F8C1C.4040407@sun.com> <20090115210520.GR884@Sun.COM> <496FA74E.2030204@sun.com> <20090115213020.GT884@Sun.COM> <496FB139.9020404@sun.com> <20090115215953.GX884@Sun.COM> <496FB4A2.5040007@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1206 On Thu, Jan 15, 2009 at 03:11:46PM -0700, Shawn M. Emery wrote: > Nicolas Williams wrote: > >On Thu, Jan 15, 2009 at 02:57:13PM -0700, Shawn M. Emery wrote: > >>Two are being considered for OpenSolaris, so within each OS there could > > > >Why? For interop with MIT krb5 user-land built by users? If MIT krb5 > >received contributions from us that #ifdef solaris the choice of IPC > >then this problem goes away. > > I was considering an all or nothing approach, rather than using > different IPC for kernel/user space. I'm in favor of using only doors for upcalls and user-land calls unless there's a need to interop with previous installations of user-built MIT krb5 CCAPI clients. > >>be options or accross multiple OS's. In any case, I am loath to > >>mix-and-match IPCs across kernel and user space as we prevent code reuse > >>and the inherit benefits that it provides (simplicity, risk, etc.). > >> > > > >Yes, me too. So why must we have two? > > > > I was really wanting to change the gssd IPC and thought doors was a good > mechanism for handling this. What are your arguments for not using > doors in this case? I'm not arguing that you not use doors. Quite the contrary. From Shawn.Emery@sun.com Thu Jan 15 14:57:47 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0FMvkYj019233 for ; Thu, 15 Jan 2009 14:57:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n0FMvgBh025257; Fri, 16 Jan 2009 06:57:45 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDJ00C01BS8GN00@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 14:57:44 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDJ001BFBS7UNB0@nwk-avmta-2.sfbay.sun.com>; Thu, 15 Jan 2009 14:57:43 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0FMvhCE008470; Thu, 15 Jan 2009 22:57:43 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDJ00001BMT9I00@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM); Thu, 15 Jan 2009 15:57:43 -0700 (MST) Received: from shawn-emerys-computer.local ([129.150.34.148]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDJ008FJBS59EC0@mail-amer.sun.com>; Thu, 15 Jan 2009 15:57:42 -0700 (MST) Date: Thu, 15 Jan 2009 15:58:12 -0700 From: "Shawn M. Emery" Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <20090115222825.GB884@Sun.COM> Sender: Shawn.Emery@sun.com To: Nicolas Williams Cc: Glenn Faden , Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <496FBF84.6030405@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <496F88C4.9060605@sun.com> <496F8AC6.1000008@sun.com> <496F8C1C.4040407@sun.com> <20090115210520.GR884@Sun.COM> <496FA74E.2030204@sun.com> <20090115213020.GT884@Sun.COM> <496FB139.9020404@sun.com> <20090115215953.GX884@Sun.COM> <496FB4A2.5040007@sun.com> <20090115222825.GB884@Sun.COM> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 1570 Nicolas Williams wrote: > On Thu, Jan 15, 2009 at 03:11:46PM -0700, Shawn M. Emery wrote: > >> Nicolas Williams wrote: >> >>> On Thu, Jan 15, 2009 at 02:57:13PM -0700, Shawn M. Emery wrote: >>> >>>> Two are being considered for OpenSolaris, so within each OS there could >>>> >>> Why? For interop with MIT krb5 user-land built by users? If MIT krb5 >>> received contributions from us that #ifdef solaris the choice of IPC >>> then this problem goes away. >>> >> I was considering an all or nothing approach, rather than using >> different IPC for kernel/user space. >> > > I'm in favor of using only doors for upcalls and user-land calls unless > there's a need to interop with previous installations of user-built MIT > krb5 CCAPI clients. > The only existing CCAPI clients that I'm aware of are for Mac and Windows. Mac uses the mach IPC and Windows uses RPC (I believe). Therefore we shouldn't break compatibility. >>>> be options or accross multiple OS's. In any case, I am loath to >>>> mix-and-match IPCs across kernel and user space as we prevent code reuse >>>> and the inherit benefits that it provides (simplicity, risk, etc.). >>>> >>>> >>> Yes, me too. So why must we have two? >>> >>> >> I was really wanting to change the gssd IPC and thought doors was a good >> mechanism for handling this. What are your arguments for not using >> doors in this case? >> > > I'm not arguing that you not use doors. Quite the contrary. > Ah, good, something we agree on :) Shawn. -- From Darren.Moffat@sun.com Mon Jan 19 06:23:47 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0JENlSd023598 for ; Mon, 19 Jan 2009 06:23:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0JENjJY045707; Mon, 19 Jan 2009 07:23:46 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDQ0050D2NJI300@nwk-avmta-2.sfbay.sun.com>; Mon, 19 Jan 2009 06:23:43 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDQ00JDI2NHWG70@nwk-avmta-2.sfbay.sun.com>; Mon, 19 Jan 2009 06:23:41 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0JENeHA027178; Mon, 19 Jan 2009 14:23:40 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDQ0030123ZDR00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Mon, 19 Jan 2009 14:23:40 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDQ00JO52NE8PE0@fe-emea-10.sun.com>; Mon, 19 Jan 2009 14:23:39 +0000 (GMT) Date: Mon, 19 Jan 2009 14:23:38 +0000 From: Darren J Moffat Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Wyllys Ingersoll Cc: PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <49748CEA.9030105@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 586 Wyllys Ingersoll wrote: > + ccache_type > + > + Contains the credential cache type used by the system. Valid values > + are "file" or "ccapi". If unspecified then the default type is "file". > + Refer to krb5envvar(5) under KRB5CCNAME for a description of each type. > + Is this sufficient so that pam_krb5 can be setup to use ccapi ? If so that is wonderful because I believe that will mean that the pam_setcred(pamh, PAM_DELETE_CRED) calls that sshd makes could actually be useful to only delete that ssh sessions krb5 creds. -- Darren J Moffat From Shawn.Emery@sun.com Tue Jan 20 00:29:09 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0K8T96F004567 for ; Tue, 20 Jan 2009 00:29:09 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0K8T3M0010341; Tue, 20 Jan 2009 00:29:08 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDR00J0JGWI2400@brm-avmta-1.central.sun.com>; Tue, 20 Jan 2009 01:29:06 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDR00A9PGWIU0D0@brm-avmta-1.central.sun.com>; Tue, 20 Jan 2009 01:29:06 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0K8T60C028328; Tue, 20 Jan 2009 08:29:06 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDR00201GTH3000@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM); Tue, 20 Jan 2009 01:29:06 -0700 (MST) Received: from [10.0.0.5] ([206.124.6.79]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDR00I49GWHQ6D0@mail-amer.sun.com>; Tue, 20 Jan 2009 01:29:05 -0700 (MST) Date: Tue, 20 Jan 2009 01:28:22 -0700 From: Shawn M Emery Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <20090115222620.GA884@Sun.COM> Sender: Shawn.Emery@sun.com To: Nicolas Williams Cc: Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <49758B26.9000302@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ZENxcrDpClyWZMGs1451bw)" X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <20090115222620.GA884@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081125) Status: RO Content-Length: 10081 This is a multi-part message in MIME format. --Boundary_(ID_ZENxcrDpClyWZMGs1451bw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Nicolas Williams wrote: > On Thu, Jan 15, 2009 at 08:42:15AM -0800, Wyllys Ingersoll wrote: > >> 1. Introduction >> >> Project will create a new credential cache type that will allow a per >> session Kerberos credential cache. The CCAPI cache type will not be >> the default credential cache type for normal initial authentication, >> it will remain "FILE". >> >> Per session ccaches is highly desirable for a number of reasons, but >> for this particular project it is required that credentials used for >> long running proccesses not interfere/overwrite credentials that are >> created from normal operations such as initial authentication or >> delegation. >> > > Given the way gssd works (even if revamped to be per-user gssd > instances), to me per-session ccache means adding a kernel-land > mechanism for associating user processes with "sessions." > > If such a mechanism is missing then this case seems incomplete. > I purposely left the session naming mechanism out of the one-pager, as I believe something more systemic needs to thought out and deserves it's own case and transcends anything in CCAPI's scope. > One possibility is that gssd (or each per-user gssd) will try all of the > per-session CCAPI daemons, as opposed to trying to find the CCAPI daemon > associated with the process that triggered the upcall to gssd. > > Either way, there's something missing here. > My primary reasoning of having the CCAPI is the ability to have multiple default credentials for purpose of separating initial login credentials and those required for long running and delayed execution processes. To this purpose all that would be required is two forms of cache naming those of delayed execution and those of initial login. To me this is an implementation detail. >> 3. Daemon >> >> New per user daemon is proposed, ccd (credential cache daemon). ccd(1M) >> contains various credential cache stores for the user. Particular >> ccache stores in the daemon are referenced by the tuple >> (uid, session id). The uid and session-id are ascii string characters. >> session id can be configurable through libraries and environment >> variable. >> > > Where are the door handles for CCAPI daemons fattach()ed? > > How are these daemons started? > > For example, gssd using doors should be started by svc.startd, not > inetd. So there's at least one architectural change that probably needs > to be described (but maybe not -- is the restarter for a service an > architectural detail?). > Yes, as it affects the FMRI, but I haven't done away with gssd yet :) > How are the CCAPI daemons started? Are they started by pam_krb5(5)? > By kinit(1)? By an IPC call from either pam_krb5(5) or kinit(1) to a > master CCAPI daemon started by SMF? > > And how are these daemons reaped? For login sessions [where pam_krb5 is > involved[ I'd expect that pam_krb5:pam_sm_close_session() takes care of > it. But if new CCAPI daemon processes can be started by kinit, then how > are they destroyed? > To me these are all implementation details that I purposely did not cover in the requirements details. But in any case, here are implementation details, for the curious: http://k5wiki.kerberos.org/wiki/Projects/CCAPI_for_UNIX under "Spawning new server and connecting". Additional advice given is that the ccache server should exit after inactivity, therefore store the ccache encrypted on disk. I think any further implementation details can be taken off list. I'm just trying to get requirements approval at this point, as I certainly don't want to paint myself in the corner on an implementation detail that I discover later on is not the most efficient/reasonable design :) >> 5. IPC >> >> Preferred form of IPC is doors, even though MIT implementation in >> Unix is domain sockets. With doors we can perform credentialling with >> native functions, e.g. door_ucred(3C). >> >> An attempt will be made to make the IPC code as portable as possible. >> > > Are people using MIT krb5 CCAPI on Solaris today? If so, that's an > argument for keeping the Unix domain socket IPC. Otherwise I'd argue > that you need to have only doors IPC. > No, just Mac and Windows users. Shawn. -- --Boundary_(ID_ZENxcrDpClyWZMGs1451bw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Nicolas Williams wrote: 
On Thu, Jan 15, 2009 at 08:42:15AM -0800, Wyllys Ingersoll wrote:
  
1.  Introduction

        Project will create a new credential cache type that will allow a per
        session Kerberos credential cache.  The CCAPI cache type will not be
	the default credential cache type for normal initial authentication,
	it will remain "FILE".

        Per session ccaches is highly desirable for a number of reasons, but
        for this particular project it is required that credentials used for
        long running proccesses not interfere/overwrite credentials that are
        created from normal operations such as initial authentication or
        delegation.
    

Given the way gssd works (even if revamped to be per-user gssd
instances), to me per-session ccache means adding a kernel-land
mechanism for associating user processes with "sessions."

If such a mechanism is missing then this case seems incomplete.
I purposely left the session naming mechanism out of the one-pager, as I believe something more systemic needs to thought out and deserves it's own case and transcends anything in CCAPI's scope.

One possibility is that gssd (or each per-user gssd) will try all of the
per-session CCAPI daemons, as opposed to trying to find the CCAPI daemon
associated with the process that triggered the upcall to gssd.

Either way, there's something missing here.

My primary reasoning of having the CCAPI is the ability to have multiple default credentials for purpose of separating initial login credentials and those required for long running and delayed execution processes.  To this purpose all that would be required is two forms of cache naming those of delayed execution and those of initial login.  To me this is an implementation detail.

3.  Daemon

        New per user daemon is proposed, ccd (credential cache daemon).  ccd(1M)
        contains various credential cache stores for the user.  Particular
        ccache stores in the daemon are referenced by the tuple
        (uid, session id).  The uid and session-id are ascii string characters.
        session id can be configurable through libraries and environment
        variable.
    

Where are the door handles for CCAPI daemons fattach()ed?

How are these daemons started?

For example, gssd using doors should be started by svc.startd, not
inetd.  So there's at least one architectural change that probably needs
to be described (but maybe not -- is the restarter for a service an
architectural detail?).

Yes, as it affects the FMRI, but I haven't done away with gssd yet :)

How are the CCAPI daemons started?  Are they started by pam_krb5(5)?
By kinit(1)?  By an IPC call from either pam_krb5(5) or kinit(1) to a
master CCAPI daemon started by SMF?

And how are these daemons reaped?  For login sessions [where pam_krb5 is
involved[ I'd expect that pam_krb5:pam_sm_close_session() takes care of
it.  But if new CCAPI daemon processes can be started by kinit, then how
are they destroyed?

To me these are all implementation details that I purposely did not cover in the requirements details.  But in any case, here are implementation details, for the curious:

http://k5wiki.kerberos.org/wiki/Projects/CCAPI_for_UNIX

under "Spawning new server and connecting".

Additional advice given is that the ccache server should exit after inactivity, therefore store the ccache encrypted on disk.

I think any further implementation details can be taken off list.  I'm just trying to get requirements approval at this point, as I certainly don't want to paint myself in the corner on an implementation detail that I discover later on is not the most efficient/reasonable design :)

5.  IPC

        Preferred form of IPC is doors, even though MIT implementation in
        Unix is domain sockets.  With doors we can perform credentialling with
        native functions, e.g. door_ucred(3C).

	An attempt will be made to make the IPC code as portable as possible.
    

Are people using MIT krb5 CCAPI on Solaris today?  If so, that's an
argument for keeping the Unix domain socket IPC.  Otherwise I'd argue
that you need to have only doors IPC.

No, just Mac and Windows users.

Shawn.
--
--Boundary_(ID_ZENxcrDpClyWZMGs1451bw)-- From Shawn.Emery@sun.com Tue Jan 20 00:29:13 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0K8TC2O004573 for ; Tue, 20 Jan 2009 00:29:12 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n0K8T98E029866; Tue, 20 Jan 2009 16:29:11 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDR00E03GWLH200@nwk-avmta-2.sfbay.sun.com>; Tue, 20 Jan 2009 00:29:09 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDR007MWGWL9O50@nwk-avmta-2.sfbay.sun.com>; Tue, 20 Jan 2009 00:29:09 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0K8T8am000723; Tue, 20 Jan 2009 08:29:09 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDR00201GTH3000@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM); Tue, 20 Jan 2009 01:29:08 -0700 (MST) Received: from [10.0.0.5] ([206.124.6.79]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDR00I4LGWKQ6D0@mail-amer.sun.com>; Tue, 20 Jan 2009 01:29:08 -0700 (MST) Date: Tue, 20 Jan 2009 01:28:25 -0700 From: Shawn M Emery Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <49748CEA.9030105@Sun.COM> Sender: Shawn.Emery@sun.com To: Darren J Moffat Cc: Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <49758B29.70807@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <49748CEA.9030105@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081125) Status: RO Content-Length: 1049 Darren J Moffat wrote: > Wyllys Ingersoll wrote: >> + ccache_type >> + >> + Contains the credential cache type used by the system. >> Valid values >> + are "file" or "ccapi". If unspecified then the default >> type is "file". >> + Refer to krb5envvar(5) under KRB5CCNAME for a description >> of each type. >> + > > Is this sufficient so that pam_krb5 can be setup to use ccapi ? If so > that is wonderful because I believe that will mean that the > pam_setcred(pamh, PAM_DELETE_CRED) calls that sshd makes could > actually be useful to only delete that ssh sessions krb5 creds. Yes, but that requires the application to inherit the environment variables of the caller. However, initial login applications need to be leery of inheriting arbitrary environment variables as the associated process could be running with privileges at times. So some refactoring is required to get this to work. Perhaps this warrants a separate case for reintroducing session management, at least for pam_krb5(5). Shawn. -- From Nicolas.Williams@sun.com Tue Jan 20 07:25:51 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0KFPoCh028341 for ; Tue, 20 Jan 2009 07:25:50 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0KFPlWk002808; Tue, 20 Jan 2009 15:25:48 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDS00H1906Y7R00@nwk-avmta-2.sfbay.sun.com>; Tue, 20 Jan 2009 07:25:46 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDS00EK806XYI50@nwk-avmta-2.sfbay.sun.com>; Tue, 20 Jan 2009 07:25:46 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0KFOYlX023974; Tue, 20 Jan 2009 09:24:34 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0KFOY4i023973; Tue, 20 Jan 2009 09:24:34 -0600 (CST) Date: Tue, 20 Jan 2009 09:24:34 -0600 From: Nicolas Williams Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <49758B26.9000302@sun.com> To: Shawn M Emery Cc: Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <20090120152434.GS884@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <20090115222620.GA884@Sun.COM> <49758B26.9000302@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 3235 On Tue, Jan 20, 2009 at 01:28:22AM -0700, Shawn M Emery wrote: > Nicolas Williams wrote: > >If such a mechanism is missing then this case seems incomplete. > > > I purposely left the session naming mechanism out of the one-pager, as I > believe something more systemic needs to thought out and deserves it's > own case and transcends anything in CCAPI's scope. Then as long as this case retains the words "per-session" it will be incomplete. Either remove those words, add the missing facility, or block on a future case that should provide it. > My primary reasoning of having the CCAPI is the ability to have multiple > default credentials for purpose of separating initial login credentials > and those required for long running and delayed execution processes. To > this purpose all that would be required is two forms of cache naming > those of delayed execution and those of initial login. To me this is an > implementation detail. Without a kernel-side hook these credentials will not be available for secure NFS on a per-session basis. Therefore this is insufficient and incomplete. > >Where are the door handles for CCAPI daemons fattach()ed? > > > >How are these daemons started? > > > >For example, gssd using doors should be started by svc.startd, not > >inetd. So there's at least one architectural change that probably needs > >to be described (but maybe not -- is the restarter for a service an > >architectural detail?). > > Yes, as it affects the FMRI, but I haven't done away with gssd yet :) Why should the FMRI change? > >How are the CCAPI daemons started? Are they started by pam_krb5(5)? > >By kinit(1)? By an IPC call from either pam_krb5(5) or kinit(1) to a > >master CCAPI daemon started by SMF? > > > >And how are these daemons reaped? For login sessions [where pam_krb5 is > >involved[ I'd expect that pam_krb5:pam_sm_close_session() takes care of > >it. But if new CCAPI daemon processes can be started by kinit, then how > >are they destroyed? > > To me these are all implementation details that I purposely did not > cover in the requirements details. But in any case, here are > implementation details, for the curious: > > http://k5wiki.kerberos.org/wiki/Projects/CCAPI_for_UNIX > > under "Spawning new server and connecting". That has implementation details, but strongly implies a UI and/or API. Those missing interfaces need to be described. (Surely the protocol described in the linked page is not intended for _users_ to execute through netcat or some such, right?) > Additional advice given is that the ccache server should exit after > inactivity, therefore store the ccache encrypted on disk. How will the daemon know when no long-running processes require it any longer? > I think any further implementation details can be taken off list. I'm > just trying to get requirements approval at this point, as I certainly > don't want to paint myself in the corner on an implementation detail > that I discover later on is not the most efficient/reasonable design :) I believe this case is incomplete as it stands. Were I an ARC member I'd ask you to address these issues and update the materials, else derail. I hope an ARC member does as much. Nico -- From Nicolas.Williams@sun.com Tue Jan 20 07:29:13 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0KFTD7c028363 for ; Tue, 20 Jan 2009 07:29:13 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0KFT5FQ027573; Tue, 20 Jan 2009 07:29:10 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDS00D1T0CJWQ00@brm-avmta-1.central.sun.com>; Tue, 20 Jan 2009 08:29:07 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDS00AL50CIPG20@brm-avmta-1.central.sun.com>; Tue, 20 Jan 2009 08:29:06 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0KFRtRw023981; Tue, 20 Jan 2009 09:27:55 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0KFRt2n023980; Tue, 20 Jan 2009 09:27:55 -0600 (CST) Date: Tue, 20 Jan 2009 09:27:55 -0600 From: Nicolas Williams Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <49758B29.70807@sun.com> To: Shawn M Emery Cc: Darren J Moffat , Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <20090120152754.GT884@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <49748CEA.9030105@Sun.COM> <49758B29.70807@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1354 On Tue, Jan 20, 2009 at 01:28:25AM -0700, Shawn M Emery wrote: > Darren J Moffat wrote: > >Is this sufficient so that pam_krb5 can be setup to use ccapi ? If so > >that is wonderful because I believe that will mean that the > >pam_setcred(pamh, PAM_DELETE_CRED) calls that sshd makes could > >actually be useful to only delete that ssh sessions krb5 creds. > > Yes, but that requires the application to inherit the environment > variables of the caller. However, initial login applications need to be > leery of inheriting arbitrary environment variables as the associated > process could be running with privileges at times. So some refactoring > is required to get this to work. Perhaps this warrants a separate case > for reintroducing session management, at least for pam_krb5(5). kgssapi (and, therefore, secure NFS) does not see user-land environment variables. Moreover, gssd doesn't know the PID of the process that triggered an upcall from kgssapi (though this would be fixed if you changed gssd to use doors), and even if it did, gssd wouldn't have access to its caller's environment variables since the only ways to get to another process' environment are: proc(4)/libproc and pargs(1), which are not really intended for this type of use (using proc(4) to get at a process' env is very heavy-weight and not reliable). Nico -- From Darren.Moffat@sun.com Tue Jan 20 08:07:24 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0KG7Noa029362 for ; Tue, 20 Jan 2009 08:07:24 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n0KG7KxH002339; Wed, 21 Jan 2009 00:07:22 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDS00K072495Q00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 20 Jan 2009 08:07:21 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDS00GN1248LH40@nwk-avmta-1.sfbay.Sun.COM>; Tue, 20 Jan 2009 08:07:21 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0KG7KUH022535; Tue, 20 Jan 2009 16:07:20 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDS008011LBY800@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 20 Jan 2009 16:07:20 +0000 (GMT) Received: from [129.156.173.215] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDS00K6323REJ10@fe-emea-09.sun.com>; Tue, 20 Jan 2009 16:07:03 +0000 (GMT) Date: Tue, 20 Jan 2009 16:07:03 +0000 From: Darren J Moffat Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <20090120152754.GT884@Sun.COM> Sender: Darren.Moffat@sun.com To: Wyllys Ingersoll Cc: Nicolas Williams , Shawn M Emery , PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <4975F6A7.30602@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <49748CEA.9030105@Sun.COM> <49758B29.70807@sun.com> <20090120152754.GT884@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Status: RO Content-Length: 170 I need more time to review the original case materials and the comments on the completeness of this case from Nico. Please extend the timer a week. -- Darren J Moffat From wyllys.ingersoll@sun.com Tue Jan 20 08:08:32 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0KG8Vs4008595 for ; Tue, 20 Jan 2009 08:08:32 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0KG8Prg029610; Tue, 20 Jan 2009 16:08:29 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDS00H67264IM00@brm-avmta-1.central.sun.com>; Tue, 20 Jan 2009 09:08:28 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDS00A9Q262PF50@brm-avmta-1.central.sun.com>; Tue, 20 Jan 2009 09:08:26 -0700 (MST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n0KG8Og6954384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2009 08:08:25 -0800 (PST) Date: Tue, 20 Jan 2009 11:08:24 -0500 From: Wyllys Ingersoll Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <4975F6A7.30602@Sun.COM> To: Darren J Moffat Cc: Wyllys Ingersoll , Nicolas Williams , Shawn M Emery , PSARC-ext@sun.com, kerberos-interest@sun.com Message-id: <4975F6F8.5060502@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <49748CEA.9030105@Sun.COM> <49758B29.70807@sun.com> <20090120152754.GT884@Sun.COM> <4975F6A7.30602@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 237 Darren J Moffat wrote: > I need more time to review the original case materials and the > comments on the completeness of this case from Nico. > > Please extend the timer a week. > > -- > Darren J Moffat I will make it so. -Wyllys From Shawn.Emery@sun.com Tue Jan 20 14:55:41 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0KMtf0p012596 for ; Tue, 20 Jan 2009 14:55:41 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0KMtb3N022773 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 20 Jan 2009 14:55:40 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDS00207L0QLW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 20 Jan 2009 14:55:38 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDS00ER8L0Q2C90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 20 Jan 2009 14:55:38 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0KMtcdV029652 for ; Tue, 20 Jan 2009 22:55:38 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDS00601IBSYV00@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 20 Jan 2009 15:55:38 -0700 (MST) Received: from [10.0.0.5] ([206.124.6.79]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDS0044YL0IW1C0@mail-amer.sun.com>; Tue, 20 Jan 2009 15:55:32 -0700 (MST) Date: Tue, 20 Jan 2009 15:54:47 -0700 From: Shawn M Emery Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <20090120152434.GS884@Sun.COM> Sender: Shawn.Emery@sun.com To: Nicolas Williams Cc: Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <49765637.1010903@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ZBOopCD1HdkctXPbCC2pqg)" X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <20090115222620.GA884@Sun.COM> <49758B26.9000302@sun.com> <20090120152434.GS884@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081125) Status: RO Content-Length: 11250 This is a multi-part message in MIME format. --Boundary_(ID_ZBOopCD1HdkctXPbCC2pqg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Changing kerberos-interest@sun.com to kerberos-discuss@opensolaris.org ... Nicolas Williams wrote: > On Tue, Jan 20, 2009 at 01:28:22AM -0700, Shawn M Emery wrote: > >> Nicolas Williams wrote: >> >>> If such a mechanism is missing then this case seems incomplete. >>> >>> >> I purposely left the session naming mechanism out of the one-pager, as I >> believe something more systemic needs to thought out and deserves it's >> own case and transcends anything in CCAPI's scope. >> > > Then as long as this case retains the words "per-session" it will be > incomplete. > > Either remove those words, add the missing facility, or block on a > future case that should provide it. > I purposely specified "will allow", "support", and "helpful" in regards to sessions. As the applications still have an interface for designing specific forms of session. If the scope of the project is to define a system level or SPI then I believe that this warrants a separate case as it impacts many applications and not necessarily specific to Kerberos. >> My primary reasoning of having the CCAPI is the ability to have multiple >> default credentials for purpose of separating initial login credentials >> and those required for long running and delayed execution processes. To >> this purpose all that would be required is two forms of cache naming >> those of delayed execution and those of initial login. To me this is an >> implementation detail. >> > > Without a kernel-side hook these credentials will not be available for > secure NFS on a per-session basis. Therefore this is insufficient and > incomplete. > Currently, gssd uses the principal to map to the local user. I believe that this is still useful and could be used in order to lookup a special CCAPI entry and to fall-back to file stores created by initial login. >>> Where are the door handles for CCAPI daemons fattach()ed? >>> >>> How are these daemons started? >>> >>> For example, gssd using doors should be started by svc.startd, not >>> inetd. So there's at least one architectural change that probably needs >>> to be described (but maybe not -- is the restarter for a service an >>> architectural detail?). >>> >> Yes, as it affects the FMRI, but I haven't done away with gssd yet :) >> > > Why should the FMRI change? > If gssd goes away then the FMRI goes from being defined to that which is not :) >>> How are the CCAPI daemons started? Are they started by pam_krb5(5)? >>> By kinit(1)? By an IPC call from either pam_krb5(5) or kinit(1) to a >>> master CCAPI daemon started by SMF? >>> >>> And how are these daemons reaped? For login sessions [where pam_krb5 is >>> involved[ I'd expect that pam_krb5:pam_sm_close_session() takes care of >>> it. But if new CCAPI daemon processes can be started by kinit, then how >>> are they destroyed? >>> >> To me these are all implementation details that I purposely did not >> cover in the requirements details. But in any case, here are >> implementation details, for the curious: >> >> http://k5wiki.kerberos.org/wiki/Projects/CCAPI_for_UNIX >> >> under "Spawning new server and connecting". >> > > That has implementation details, but strongly implies a UI and/or API. > Those missing interfaces need to be described. (Surely the protocol > described in the linked page is not intended for _users_ to execute > through netcat or some such, right?) > Hmmm, locking down specific things like timing on process reaping might paint oneself in the corner in a requirements document. >> Additional advice given is that the ccache server should exit after >> inactivity, therefore store the ccache encrypted on disk. >> > > How will the daemon know when no long-running processes require it any > longer? > Not to paint myself in corner, x minutes. >> I think any further implementation details can be taken off list. I'm >> just trying to get requirements approval at this point, as I certainly >> don't want to paint myself in the corner on an implementation detail >> that I discover later on is not the most efficient/reasonable design :) >> > > I believe this case is incomplete as it stands. Were I an ARC member > I'd ask you to address these issues and update the materials, else > derail. I hope an ARC member does as much. > I certainly think that the session id SPI is a much needed project, however I don't think that it should be lumped into the CCAPI project. I can't decide on my own that CCAPI would block on a session id project, but I will certainly argue on both sides. Shawn. -- --Boundary_(ID_ZBOopCD1HdkctXPbCC2pqg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Changing kerberos-interest@sun.com to kerberos-discuss@opensolaris.org ...

Nicolas Williams wrote: 
On Tue, Jan 20, 2009 at 01:28:22AM -0700, Shawn M Emery wrote:
  
Nicolas Williams wrote:
    
If such a mechanism is missing then this case seems incomplete.
 
      
I purposely left the session naming mechanism out of the one-pager, as I 
believe something more systemic needs to thought out and deserves it's 
own case and transcends anything in CCAPI's scope.
    

Then as long as this case retains the words "per-session" it will be
incomplete.

Either remove those words, add the missing facility, or block on a
future case that should provide it.

I purposely specified "will allow", "support", and "helpful" in regards to sessions.  As the applications still have an interface for designing specific forms of session.  If the scope of the project is to define a system level or SPI then I believe that this warrants a separate case as it impacts many applications and not necessarily specific to Kerberos.

My primary reasoning of having the CCAPI is the ability to have multiple 
default credentials for purpose of separating initial login credentials 
and those required for long running and delayed execution processes.  To 
this purpose all that would be required is two forms of cache naming 
those of delayed execution and those of initial login.  To me this is an 
implementation detail.
    

Without a kernel-side hook these credentials will not be available for
secure NFS on a per-session basis.  Therefore this is insufficient and
incomplete.

Currently, gssd uses the principal to map to the local user.  I believe that this is still useful and could be used in order to lookup a special CCAPI entry and to fall-back to file stores created by initial login.

Where are the door handles for CCAPI daemons fattach()ed?

How are these daemons started?

For example, gssd using doors should be started by svc.startd, not
inetd.  So there's at least one architectural change that probably needs
to be described (but maybe not -- is the restarter for a service an
architectural detail?).
      
Yes, as it affects the FMRI, but I haven't done away with gssd yet :)
    

Why should the FMRI change?

If gssd goes away then the FMRI goes from being defined to that which is not :)

How are the CCAPI daemons started?  Are they started by pam_krb5(5)?
By kinit(1)?  By an IPC call from either pam_krb5(5) or kinit(1) to a
master CCAPI daemon started by SMF?

And how are these daemons reaped?  For login sessions [where pam_krb5 is
involved[ I'd expect that pam_krb5:pam_sm_close_session() takes care of
it.  But if new CCAPI daemon processes can be started by kinit, then how
are they destroyed?
      
To me these are all implementation details that I purposely did not 
cover in the requirements details.  But in any case, here are 
implementation details, for the curious:

http://k5wiki.kerberos.org/wiki/Projects/CCAPI_for_UNIX

under "Spawning new server and connecting".
    

That has implementation details, but strongly implies a UI and/or API.
Those missing interfaces need to be described.  (Surely the protocol
described in the linked page is not intended for _users_ to execute
through netcat or some such, right?)

Hmmm, locking down specific things like timing on process reaping might paint oneself in the corner in a requirements document.

Additional advice given is that the ccache server should exit after 
inactivity, therefore store the ccache encrypted on disk.
    

How will the daemon know when no long-running processes require it any
longer?

Not to paint myself in corner, x minutes.

I think any further implementation details can be taken off list.  I'm 
just trying to get requirements approval at this point, as I certainly 
don't want to paint myself in the corner on an implementation detail 
that I discover later on is not the most efficient/reasonable design :)
    

I believe this case is incomplete as it stands.  Were I an ARC member
I'd ask you to address these issues and update the materials, else
derail.  I hope an ARC member does as much.

I certainly think that the session id SPI is a much needed project, however I don't think that it should be lumped into the CCAPI project.  I can't decide on my own that CCAPI would block on a session id project, but I will certainly argue on both sides.

Shawn.
--
--Boundary_(ID_ZBOopCD1HdkctXPbCC2pqg)-- From deengert@anl.gov Wed Jan 21 07:52:35 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0LFqZu9029927 for ; Wed, 21 Jan 2009 07:52:35 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0LFqWUX012859; Wed, 21 Jan 2009 07:52:34 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDT00K0HW3CNT00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Jan 2009 07:52:24 -0800 (PST) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDT00HIEW3BLB20@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Jan 2009 07:52:23 -0800 (PST) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24] (may be forged)) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0LFqNxU016888; Wed, 21 Jan 2009 15:52:23 +0000 (GMT) Received: from mms25es.mms.us.syntegra.com ([150.143.232.90] [150.143.232.90]) by relay21i.sun.com with ESMTP id BT-MMP-3353364; Wed, 21 Jan 2009 15:52:23 +0000 (Z) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24]) by mms25es.mms.us.syntegra.com with ESMTP id BT-MMP-1798235; Wed, 21 Jan 2009 15:52:22 +0000 (Z) Received: from mailhost.anl.gov ([130.202.113.50] [130.202.113.50]) by relay21i.sun.com with ESMTP id BT-MMP-16462881; Wed, 21 Jan 2009 15:52:22 +0000 (Z) Received: from mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id E16EC33; Wed, 21 Jan 2009 09:52:21 -0600 (CST) Received: from [127.0.0.1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id B61D62F; Wed, 21 Jan 2009 09:52:21 -0600 (CST) Date: Wed, 21 Jan 2009 09:52:21 -0600 From: "Douglas E. Engert" Subject: Re: [kerberos-discuss] Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <49765637.1010903@sun.com> To: Shawn M Emery Cc: Nicolas Williams , Wyllys Ingersoll , kerberos-discuss@opensolaris.org, PSARC-ext@sun.com Message-id: <497744B5.8000805@anl.gov> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.308sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <20090115222620.GA884@Sun.COM> <49758B26.9000302@sun.com> <20090120152434.GS884@Sun.COM> <49765637.1010903@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 6458 Shawn M Emery wrote: > > Changing kerberos-interest@sun.com to kerberos-discuss@opensolaris.org ... > > Nicolas Williams wrote: >> On Tue, Jan 20, 2009 at 01:28:22AM -0700, Shawn M Emery wrote: >> >>> Nicolas Williams wrote: >>> >>>> If such a mechanism is missing then this case seems incomplete. >>>> >>>> >>> I purposely left the session naming mechanism out of the one-pager, as I >>> believe something more systemic needs to thought out and deserves it's >>> own case and transcends anything in CCAPI's scope. >>> >> >> Then as long as this case retains the words "per-session" it will be >> incomplete. >> >> Either remove those words, add the missing facility, or block on a >> future case that should provide it. >> > > I purposely specified "will allow", "support", and "helpful" in regards > to sessions. As the applications still have an interface for designing > specific forms of session. If the scope of the project is to define a > system level or SPI then I believe that this warrants a separate case as > it impacts many applications and not necessarily specific to Kerberos. > >>> My primary reasoning of having the CCAPI is the ability to have multiple >>> default credentials for purpose of separating initial login credentials >>> and those required for long running and delayed execution processes. To >>> this purpose all that would be required is two forms of cache naming >>> those of delayed execution and those of initial login. To me this is an >>> implementation detail. >>> I wish you would try and make this more generic, and allow multiple credentials, and not just for delayed execution. There are times when a user may which to switch to using a different principal to access a file system for example, or when a user su's to root but keeps access to the same network file access. (We use session based cache names with sshd at least, and AFS for a shared network file system, that is capable of using the different caches.) >> >> Without a kernel-side hook these credentials will not be available for >> secure NFS on a per-session basis. Therefore this is insufficient and >> incomplete. >> Yes the issue alway seams to come back to gssd can't do it, so it can't be done. AFS and DCE used PAGs, and DCE would use the PAG number as part of a cache name, so it can be done in the kernel. > > Currently, gssd uses the principal to map to the local user. I believe > that this is still useful and could be used in order to lookup a special > CCAPI entry and to fall-back to file stores created by initial login. You really need to get away form relying on UID for the mapping and look at PAGs, keyrings, or some other method to use instead of UID to identify credentials. IMHO, possession of a UID by the kernel for a process is in effect a credential. But the credential is is only good for file systems controlled by the kernel. So a process with a UID may want to also possess other credential too for access to other file systems independent of the UID, and doing a su command in effect is changing only the UID credential, not necessarily other credentials used to access other file systems. > >>>> Where are the door handles for CCAPI daemons fattach()ed? >>>> >>>> How are these daemons started? >>>> >>>> For example, gssd using doors should be started by svc.startd, not >>>> inetd. So there's at least one architectural change that probably needs >>>> to be described (but maybe not -- is the restarter for a service an >>>> architectural detail?). >>>> >>> Yes, as it affects the FMRI, but I haven't done away with gssd yet :) >>> >> >> Why should the FMRI change? >> > > If gssd goes away then the FMRI goes from being defined to that which is > not :) > >>>> How are the CCAPI daemons started? Are they started by pam_krb5(5)? >>>> By kinit(1)? By an IPC call from either pam_krb5(5) or kinit(1) to a >>>> master CCAPI daemon started by SMF? >>>> >>>> And how are these daemons reaped? For login sessions [where pam_krb5 is >>>> involved[ I'd expect that pam_krb5:pam_sm_close_session() takes care of >>>> it. But if new CCAPI daemon processes can be started by kinit, then how >>>> are they destroyed? >>>> >>> To me these are all implementation details that I purposely did not >>> cover in the requirements details. But in any case, here are >>> implementation details, for the curious: >>> >>> http://k5wiki.kerberos.org/wiki/Projects/CCAPI_for_UNIX >>> >>> under "Spawning new server and connecting". >>> >> >> That has implementation details, but strongly implies a UI and/or API. >> Those missing interfaces need to be described. (Surely the protocol >> described in the linked page is not intended for _users_ to execute >> through netcat or some such, right?) >> > > Hmmm, locking down specific things like timing on process reaping might > paint oneself in the corner in a requirements document. > >>> Additional advice given is that the ccache server should exit after >>> inactivity, therefore store the ccache encrypted on disk. >>> >> >> How will the daemon know when no long-running processes require it any >> longer? >> > > Not to paint myself in corner, x minutes. > >>> I think any further implementation details can be taken off list. I'm >>> just trying to get requirements approval at this point, as I certainly >>> don't want to paint myself in the corner on an implementation detail >>> that I discover later on is not the most efficient/reasonable design :) >>> >> >> I believe this case is incomplete as it stands. Were I an ARC member >> I'd ask you to address these issues and update the materials, else >> derail. I hope an ARC member does as much. >> > > I certainly think that the session id SPI is a much needed project, > however I don't think that it should be lumped into the CCAPI project. > I can't decide on my own that CCAPI would block on a session id project, > but I will certainly argue on both sides. > > Shawn. > -- > > > ------------------------------------------------------------------------ > > _______________________________________________ > kerberos-discuss mailing list > kerberos-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/kerberos-discuss -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From Nicolas.Williams@sun.com Mon Jan 26 11:37:40 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0QJbeVX022789 for ; Mon, 26 Jan 2009 11:37:40 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0QJbcdk001021; Mon, 26 Jan 2009 11:37:40 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE300N01FUR0600@brm-avmta-1.central.sun.com>; Mon, 26 Jan 2009 12:37:39 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE300HS0FUQ0G30@brm-avmta-1.central.sun.com>; Mon, 26 Jan 2009 12:37:38 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0QJLL6N003592; Mon, 26 Jan 2009 13:21:21 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0QJLLjK003591; Mon, 26 Jan 2009 13:21:21 -0600 (CST) Date: Mon, 26 Jan 2009 13:21:21 -0600 From: Nicolas Williams Subject: Re: [kerberos-discuss] Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <497744B5.8000805@anl.gov> To: "Douglas E. Engert" Cc: Shawn M Emery , Wyllys Ingersoll , kerberos-discuss@opensolaris.org, PSARC-ext@sun.com Message-id: <20090126192121.GR1044@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200901151642.n0FGgFwN020743@sac.sfbay.sun.com> <20090115222620.GA884@Sun.COM> <49758B26.9000302@sun.com> <20090120152434.GS884@Sun.COM> <49765637.1010903@sun.com> <497744B5.8000805@anl.gov> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1981 On Wed, Jan 21, 2009 at 09:52:21AM -0600, Douglas E. Engert wrote: > I wish you would try and make this more generic, and allow multiple > credentials, and not just for delayed execution. There are times when > a user may which to switch to using a different principal to access a > file system for example, or when a user su's to root but keeps access > to the same network file access. It's one thing to say that a Unix user has multiple network authentication credentials (Kerberos V, PKI, whatever) to be used by the system when talking to various different services, and it's another to say that a Unix user not only has multiple such credentials, but that for any one service they can switch between them. The former can be implemented in Solaris as-is by adding suitable identity selection facilities to SASL/GSS-API/whatever mechanisms. The latter requires something like AFS PAGs or Linux kernel keyrings in order to enable the grouping of processes running as one user that should be asserting one identity to some set of services vs another group of processes running as the same user but asserting a different ID to that same set of services. It is precisely because ID selection is such a difficult UI problem that the latter approach is so alluring. > (We use session based cache names with sshd at least, and AFS for a shared > network file system, that is capable of using the different caches.) Understood. > >Currently, gssd uses the principal to map to the local user. I believe > >that this is still useful and could be used in order to lookup a special > >CCAPI entry and to fall-back to file stores created by initial login. > > You really need to get away form relying on UID for the mapping and > look at PAGs, keyrings, or some other method to use instead of UID to > identify credentials. We agree. However, this case is just not that case; this case is independent of a case that would bring AFS PAG-like functionality to Solaris. Nico -- From gww@eng.sun.com Tue Jan 27 13:15:13 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0RLFD5c011228 for ; Tue, 27 Jan 2009 13:15:13 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0RLF0ei050086; Tue, 27 Jan 2009 14:15:12 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE500705F1AOR00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Jan 2009 13:15:10 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE500BS3F1AXF90@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Jan 2009 13:15:10 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0RLFAHp033287; Tue, 27 Jan 2009 13:15:10 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id n0RLE4fM009529; Tue, 27 Jan 2009 13:14:04 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id n0RLE4kX009528; Tue, 27 Jan 2009 13:14:04 -0800 (PST) Date: Tue, 27 Jan 2009 13:14:04 -0800 (PST) From: Gary Winiger Subject: Re: Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] To: PSARC-ext@sun.com, wyllys@sac.sfbay.sun.com Cc: kerberos-interest@sun.com Message-id: <200901272114.n0RLE4kX009528@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 773 > 4. Technical Description I must say having read through this case, it is non-obvious to me what is being proposed and how it solves the problem of delayed execution. Perhaps I missed it, what's the relationship between gssd and ccd? Is there a persistent (i.e., across reboot) credential cache such that delayed execution jobs will run on a freshly booted system? To me the works "per session" mean beween the time of authentication to the exit of that "process group". Is there a different definition for this case? How does this all relate to a per-user ccd? On a SRSS server with 100s of users, will there be 100s of ccd/gssd-s? When and how is the per-user cache "destroyed"? I suspect I'm missing something simple/obvious about this case. Gary.. From Shawn.Emery@sun.com Mon Feb 2 01:19:09 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n129J8Kw001927 for ; Mon, 2 Feb 2009 01:19:08 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n129IIaR024875; Mon, 2 Feb 2009 09:19:01 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEF0040DLVI2500@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Feb 2009 01:18:54 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEF00E57LVHBBA0@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Feb 2009 01:18:53 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n129Irb2005669; Mon, 02 Feb 2009 09:18:53 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KEF00G01LPLED00@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM); Mon, 02 Feb 2009 02:18:53 -0700 (MST) Received: from [10.0.0.5] ([206.124.6.79]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KEF002E9LVGFF70@mail-amer.sun.com>; Mon, 02 Feb 2009 02:18:53 -0700 (MST) Date: Mon, 02 Feb 2009 02:17:58 -0700 From: Shawn M Emery Subject: Re: [kerberos-discuss] Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <200901272114.n0RLE4kX009528@marduk.eng.sun.com> Sender: Shawn.Emery@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, wyllys@sac.sfbay.sun.com, kerberos-interest@sun.com Message-id: <4986BA46.20107@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_c1hPOnj8Uv7HY1Kd9b+98g)" X-PMX-Version: 5.4.1.325704 References: <200901272114.n0RLE4kX009528@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081125) Status: RO Content-Length: 5499 This is a multi-part message in MIME format. --Boundary_(ID_c1hPOnj8Uv7HY1Kd9b+98g) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Response to questions in-line: Gary Winiger wrote: >> 4. Technical Description >> > > I must say having read through this case, it is non-obvious to > me what is being proposed and how it solves the problem of delayed > Besides the internal and external presentations I have given on the overall project, perhaps I should file an umbrella PSARC case that outlines the three projects together and how they interact? > execution. Perhaps I missed it, what's the relationship between gssd and ccd? > For Kerberos, gssd is a client of ccd, just like any other application obtaining service tickets. > Is there a persistent (i.e., across reboot) credential cache such that delayed execution jobs will run on a freshly booted system? > No, this is part of the future project of getting initial credentials (gic) through keytab PAM module project. > To me the works "per session" mean beween the time of authentication to the exit of that "process group". Is there a different definition for this case? No, this case is specific to delayed execution, which uses its own session identifier for processes such as cron/at or anything else that uses the gic through keytab module. This would have a fall-back mechanism to FILE ccaches, if CCAPI failed. > How does this all relate to a per-user ccd? > See above. > On a SRSS server with 100s of users, will there be 100s of ccd/gssd-s? As described in the one-pager, the plan is not to make the CCAPI the default credential cache as to minimize impact in environments such as this. > When and how is the per-user cache "destroyed"? > kdestroy(1) or after x minutes of inactivity, afterall initialization of credentials is dynamic with cron, as the PAM module would perform a gic w/keytab during cron's setcred pass. This has an advantage of not having to change applications. With the new module, you could also gic keytab at intervals by creating a simple application. Shawn. -- --Boundary_(ID_c1hPOnj8Uv7HY1Kd9b+98g) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Response to questions in-line:

Gary Winiger wrote: 
4. Technical Description
    

	I must say having read through this case, it is non-obvious to
	me what is being proposed and how it solves the problem of delayed

Besides the internal and external presentations I have given on the overall project, perhaps I should file an umbrella PSARC case that outlines the three projects together and how they interact?

	execution.  Perhaps I missed it, what's the relationship between gssd and 		ccd?

For Kerberos, gssd is a client of ccd, just like any other application obtaining service tickets.

Is there a persistent (i.e., across reboot) credential cache such that delayed execution jobs will run on a freshly booted system?

No, this is part of the future project of getting initial credentials (gic) through keytab PAM module project.

	To me the works "per session" mean beween the time of authentication to the exit of that "process group".  Is there a different definition for this case?

No, this case is specific to delayed execution, which uses its own session identifier for processes such as cron/at or anything else that uses the gic through keytab module.  This would have a fall-back mechanism to FILE ccaches, if CCAPI failed.

How does this all relate to a per-user ccd?

See above.

On a SRSS server with 100s of users, will there be 100s of ccd/gssd-s?

As described in the one-pager, the plan is not to make the CCAPI the default credential cache as to minimize impact in environments such as this.

When and how is the per-user cache "destroyed"?

kdestroy(1) or after x minutes of inactivity, afterall initialization of credentials is dynamic with cron, as the PAM module would perform a gic w/keytab during cron's setcred pass.  This has an advantage of not having to change applications.  With the new module, you could also gic keytab at intervals by creating a simple application.

Shawn.
--
--Boundary_(ID_c1hPOnj8Uv7HY1Kd9b+98g)-- From Richard.Matthews@Sun.COM Wed Feb 4 10:16:34 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n14IGXTF028701 for ; Wed, 4 Feb 2009 10:16:34 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n14IGQiM001338; Wed, 4 Feb 2009 18:16:32 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEK00E2303J6V00@nwk-avmta-2.sfbay.sun.com>; Wed, 04 Feb 2009 10:16:31 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEK00AG803I7M70@nwk-avmta-2.sfbay.sun.com>; Wed, 04 Feb 2009 10:16:30 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n14IGUqx017919; Wed, 04 Feb 2009 18:16:30 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEJ00100ZT3RB00@mail-amer.sun.com>; Wed, 04 Feb 2009 11:16:30 -0700 (MST) Received: from [129.152.9.11] ([unknown] [129.152.9.11]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEK00A2H03F1M10@mail-amer.sun.com>; Wed, 04 Feb 2009 11:16:28 -0700 (MST) Date: Wed, 04 Feb 2009 12:16:27 -0600 From: Rick Matthews Subject: Re: [kerberos-discuss] Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <4986BA46.20107@sun.com> Sender: Richard.Matthews@Sun.COM To: Shawn M Emery Cc: Gary Winiger , PSARC-ext@Sun.COM, wyllys@sac.sfbay.sun.com, kerberos-interest@Sun.COM Reply-to: Richard.Matthews@Sun.COM Message-id: <4989DB7B.2060500@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_XOujdyEfwhgRBjwm8y/bIg)" X-PMX-Version: 5.4.1.325704 References: <200901272114.n0RLE4kX009528@marduk.eng.sun.com> <4986BA46.20107@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 7392 This is a multi-part message in MIME format. --Boundary_(ID_XOujdyEfwhgRBjwm8y/bIg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Shawn, I think there continues to be lack of understanding on this fast-track. Your suggestion of an umbrella case is a good one. I'd like to de-rail this case until that umbrella has occurred. -- Rick On 02/02/09 03:17, Shawn M Emery wrote: > Response to questions in-line: > > Gary Winiger wrote: >>> 4. Technical Description >>> >> >> I must say having read through this case, it is non-obvious to >> me what is being proposed and how it solves the problem of delayed >> > > Besides the internal and external presentations I have given on the > overall project, perhaps I should file an umbrella PSARC case that > outlines the three projects together and how they interact? > >> execution. Perhaps I missed it, what's the relationship between gssd and ccd? >> > > For Kerberos, gssd is a client of ccd, just like any other application > obtaining service tickets. > >> Is there a persistent (i.e., across reboot) credential cache such that delayed execution jobs will run on a freshly booted system? >> > > No, this is part of the future project of getting initial credentials > (gic) through keytab PAM module project. > >> To me the works "per session" mean beween the time of authentication to the exit of that "process group". Is there a different definition for this case? > > No, this case is specific to delayed execution, which uses its own > session identifier for processes such as cron/at or anything else that > uses the gic through keytab module. This would have a fall-back > mechanism to FILE ccaches, if CCAPI failed. > >> How does this all relate to a per-user ccd? >> > > See above. > >> On a SRSS server with 100s of users, will there be 100s of ccd/gssd-s? > > As described in the one-pager, the plan is not to make the CCAPI the > default credential cache as to minimize impact in environments such as > this. > >> When and how is the per-user cache "destroyed"? >> > > kdestroy(1) or after x minutes of inactivity, afterall initialization > of credentials is dynamic with cron, as the PAM module would perform a > gic w/keytab during cron's setcred pass. This has an advantage of not > having to change applications. With the new module, you could also > gic keytab at intervals by creating a simple application. > > Shawn. > -- -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- --Boundary_(ID_XOujdyEfwhgRBjwm8y/bIg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Shawn,
  I think there continues to be lack of understanding on this fast-track. Your suggestion of an umbrella
case is a good one. I'd like to de-rail this case until that umbrella has occurred.
--
Rick

On 02/02/09 03:17, Shawn M Emery wrote:
Response to questions in-line:

Gary Winiger wrote: 
4. Technical Description
    

	I must say having read through this case, it is non-obvious to
	me what is being proposed and how it solves the problem of delayed

Besides the internal and external presentations I have given on the overall project, perhaps I should file an umbrella PSARC case that outlines the three projects together and how they interact?

	execution.  Perhaps I missed it, what's the relationship between gssd and 		ccd?

For Kerberos, gssd is a client of ccd, just like any other application obtaining service tickets.

Is there a persistent (i.e., across reboot) credential cache such that delayed execution jobs will run on a freshly booted system?

No, this is part of the future project of getting initial credentials (gic) through keytab PAM module project.

	To me the works "per session" mean beween the time of authentication to the exit of that "process group".  Is there a different definition for this case?

No, this case is specific to delayed execution, which uses its own session identifier for processes such as cron/at or anything else that uses the gic through keytab module.  This would have a fall-back mechanism to FILE ccaches, if CCAPI failed.

How does this all relate to a per-user ccd?

See above.

On a SRSS server with 100s of users, will there be 100s of ccd/gssd-s?

As described in the one-pager, the plan is not to make the CCAPI the default credential cache as to minimize impact in environments such as this.

When and how is the per-user cache "destroyed"?

kdestroy(1) or after x minutes of inactivity, afterall initialization of credentials is dynamic with cron, as the PAM module would perform a gic w/keytab during cron's setcred pass.  This has an advantage of not having to change applications.  With the new module, you could also gic keytab at intervals by creating a simple application.

Shawn.
--


-- 
---------------------------------------------------------------------
Rick Matthews                           email: Rick.Matthews@sun.com
Sun Microsystems, Inc.                  phone:+1(651) 554-1518
1270 Eagan Industrial Road              phone(internal): 54418
Suite 160                               fax:  +1(651) 554-1540
Eagan, MN 55121-1231 USA                main: +1(651) 554-1500		
---------------------------------------------------------------------
--Boundary_(ID_XOujdyEfwhgRBjwm8y/bIg)-- From Shawn.Emery@Sun.COM Wed Feb 4 10:24:10 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n14IO925029111 for ; Wed, 4 Feb 2009 10:24:09 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n14IO8Oq023850; Wed, 4 Feb 2009 10:24:09 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEK00F0N0G76V00@brm-avmta-1.central.sun.com>; Wed, 04 Feb 2009 11:24:07 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEK00NCT0G30VD0@brm-avmta-1.central.sun.com>; Wed, 04 Feb 2009 11:24:03 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n14IO3Em005579; Wed, 04 Feb 2009 18:24:03 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEJ00F00XSFC200@mail-amer.sun.com>; Wed, 04 Feb 2009 11:24:03 -0700 (MST) Received: from [10.0.0.5] ([unknown] [206.124.6.79]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEK00DK50FUKOD0@mail-amer.sun.com>; Wed, 04 Feb 2009 11:23:55 -0700 (MST) Date: Wed, 04 Feb 2009 11:22:57 -0700 From: Shawn M Emery Subject: Re: [kerberos-discuss] Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <4989DB7B.2060500@Sun.COM> Sender: Shawn.Emery@Sun.COM To: Richard.Matthews@Sun.COM Cc: Gary Winiger , PSARC-ext@Sun.COM, wyllys@sac.sfbay.sun.com, kerberos-interest@Sun.COM Message-id: <4989DD01.9000002@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_RAUqbNfxSlhNgn34VH2WMw)" X-PMX-Version: 5.4.1.325704 References: <200901272114.n0RLE4kX009528@marduk.eng.sun.com> <4986BA46.20107@sun.com> <4989DB7B.2060500@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081125) Status: RO Content-Length: 7969 This is a multi-part message in MIME format. --Boundary_(ID_RAUqbNfxSlhNgn34VH2WMw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Rick Matthews wrote: > Shawn, > I think there continues to be lack of understanding on this > fast-track. Your suggestion of an umbrella > case is a good one. I'd like to de-rail this case until that umbrella > has occurred. Ok, I will write one up shortly. Shawn. -- > On 02/02/09 03:17, Shawn M Emery wrote: >> Response to questions in-line: >> >> Gary Winiger wrote: >>>> 4. Technical Description >>>> >>> >>> I must say having read through this case, it is non-obvious to >>> me what is being proposed and how it solves the problem of delayed >>> >> >> Besides the internal and external presentations I have given on the >> overall project, perhaps I should file an umbrella PSARC case that >> outlines the three projects together and how they interact? >> >>> execution. Perhaps I missed it, what's the relationship between gssd and ccd? >>> >> >> For Kerberos, gssd is a client of ccd, just like any other >> application obtaining service tickets. >> >>> Is there a persistent (i.e., across reboot) credential cache such that delayed execution jobs will run on a freshly booted system? >>> >> >> No, this is part of the future project of getting initial credentials >> (gic) through keytab PAM module project. >> >>> To me the works "per session" mean beween the time of authentication to the exit of that "process group". Is there a different definition for this case? >> >> No, this case is specific to delayed execution, which uses its own >> session identifier for processes such as cron/at or anything else >> that uses the gic through keytab module. This would have a fall-back >> mechanism to FILE ccaches, if CCAPI failed. >> >>> How does this all relate to a per-user ccd? >>> >> >> See above. >> >>> On a SRSS server with 100s of users, will there be 100s of ccd/gssd-s? >> >> As described in the one-pager, the plan is not to make the CCAPI the >> default credential cache as to minimize impact in environments such >> as this. >> >>> When and how is the per-user cache "destroyed"? >>> >> >> kdestroy(1) or after x minutes of inactivity, afterall initialization >> of credentials is dynamic with cron, as the PAM module would perform >> a gic w/keytab during cron's setcred pass. This has an advantage of >> not having to change applications. With the new module, you could >> also gic keytab at intervals by creating a simple application. >> >> Shawn. >> -- > > > -- > --------------------------------------------------------------------- > Rick Matthews email: Rick.Matthews@sun.com > Sun Microsystems, Inc. phone:+1(651) 554-1518 > 1270 Eagan Industrial Road phone(internal): 54418 > Suite 160 fax: +1(651) 554-1540 > Eagan, MN 55121-1231 USA main: +1(651) 554-1500 > --------------------------------------------------------------------- > --Boundary_(ID_RAUqbNfxSlhNgn34VH2WMw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Rick Matthews wrote:
Shawn,
  I think there continues to be lack of understanding on this fast-track. Your suggestion of an umbrella
case is a good one. I'd like to de-rail this case until that umbrella has occurred.

Ok, I will write one up shortly.

Shawn.
--
On 02/02/09 03:17, Shawn M Emery wrote:
Response to questions in-line:

Gary Winiger wrote: 
4. Technical Description
    

	I must say having read through this case, it is non-obvious to
	me what is being proposed and how it solves the problem of delayed

Besides the internal and external presentations I have given on the overall project, perhaps I should file an umbrella PSARC case that outlines the three projects together and how they interact?

	execution.  Perhaps I missed it, what's the relationship between gssd and 		ccd?

For Kerberos, gssd is a client of ccd, just like any other application obtaining service tickets.

Is there a persistent (i.e., across reboot) credential cache such that delayed execution jobs will run on a freshly booted system?

No, this is part of the future project of getting initial credentials (gic) through keytab PAM module project.

	To me the works "per session" mean beween the time of authentication to the exit of that "process group".  Is there a different definition for this case?

No, this case is specific to delayed execution, which uses its own session identifier for processes such as cron/at or anything else that uses the gic through keytab module.  This would have a fall-back mechanism to FILE ccaches, if CCAPI failed.

How does this all relate to a per-user ccd?

See above.

On a SRSS server with 100s of users, will there be 100s of ccd/gssd-s?

As described in the one-pager, the plan is not to make the CCAPI the default credential cache as to minimize impact in environments such as this.

When and how is the per-user cache "destroyed"?

kdestroy(1) or after x minutes of inactivity, afterall initialization of credentials is dynamic with cron, as the PAM module would perform a gic w/keytab during cron's setcred pass.  This has an advantage of not having to change applications.  With the new module, you could also gic keytab at intervals by creating a simple application.

Shawn.
--


-- 
---------------------------------------------------------------------
Rick Matthews                           email: Rick.Matthews@sun.com
Sun Microsystems, Inc.                  phone:+1(651) 554-1518
1270 Eagan Industrial Road              phone(internal): 54418
Suite 160                               fax:  +1(651) 554-1540
Eagan, MN 55121-1231 USA                main: +1(651) 554-1500		
---------------------------------------------------------------------

--Boundary_(ID_RAUqbNfxSlhNgn34VH2WMw)-- From Richard.Matthews@sun.com Tue Mar 3 10:08:37 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n23I8aeh006291 for ; Tue, 3 Mar 2009 10:08:36 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n23I8VO1064581 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 3 Mar 2009 11:08:36 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFX00G3RZQBA300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 10:08:35 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFX00CLAZQ9S450@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 10:08:34 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n23I8X5r014926 for ; Tue, 03 Mar 2009 18:08:33 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFX00800YN85S00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 11:08:33 -0700 (MST) Received: from [129.152.9.11] ([unknown] [129.152.9.11]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFX00FPQZQ69RE0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 11:08:31 -0700 (MST) Date: Tue, 03 Mar 2009 12:08:29 -0600 From: Rick Matthews Subject: Re: [kerberos-discuss] Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <4989DB7B.2060500@Sun.COM> Sender: Richard.Matthews@sun.com To: Shawn Emery , Wyllys Ingersoll , PSARC-ext@sun.com Reply-to: Richard.Matthews@sun.com Message-id: <49AD721D.3070301@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ywmEGN1dWCU3jjq4sYKePQ)" X-PMX-Version: 5.4.1.325704 References: <200901272114.n0RLE4kX009528@marduk.eng.sun.com> <4986BA46.20107@sun.com> <4989DB7B.2060500@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 2686 This is a multi-part message in MIME format. --Boundary_(ID_ywmEGN1dWCU3jjq4sYKePQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Shawn, Correct me if I'm wrong, but I think you were going to do an umbrella clarifying this case. Wyllys, I think this should be in "waiting needs spec" until then. Thanks -- On 02/04/09 12:16, Rick Matthews wrote: > Shawn, > I think there continues to be lack of understanding on this > fast-track. Your suggestion of an umbrella > case is a good one. I'd like to de-rail this case until that umbrella > has occurred. > -- > Rick > > -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- --Boundary_(ID_ywmEGN1dWCU3jjq4sYKePQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Shawn,
  Correct me if I'm wrong, but I think you were going to do an umbrella clarifying this case.
Wyllys, I think this should be in "waiting needs spec" until then.
Thanks
--
On 02/04/09 12:16, Rick Matthews wrote:
Shawn,
  I think there continues to be lack of understanding on this fast-track. Your suggestion of an umbrella
case is a good one. I'd like to de-rail this case until that umbrella has occurred.
--
Rick


-- 
---------------------------------------------------------------------
Rick Matthews                           email: Rick.Matthews@sun.com
Sun Microsystems, Inc.                  phone:+1(651) 554-1518
1270 Eagan Industrial Road              phone(internal): 54418
Suite 160                               fax:  +1(651) 554-1540
Eagan, MN 55121-1231 USA                main: +1(651) 554-1500		
---------------------------------------------------------------------
--Boundary_(ID_ywmEGN1dWCU3jjq4sYKePQ)-- From hotz@jpl.nasa.gov Tue Mar 3 10:43:43 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n23Ihg8h007033 for ; Tue, 3 Mar 2009 10:43:43 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n23IhV2R017756; Wed, 4 Mar 2009 02:43:38 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFY00G011COZK00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Mar 2009 10:43:36 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFY00IV41CNR8C0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Mar 2009 10:43:35 -0800 (PST) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n23IQ6fb028826; Tue, 03 Mar 2009 18:43:35 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay13i.sun.com with ESMTP id BT-MMP-1061678; Tue, 03 Mar 2009 18:43:35 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-15497228; Tue, 03 Mar 2009 18:43:34 +0000 (Z) Received: from mail.jpl.nasa.gov ([128.149.139.105] [128.149.139.105]) by relay1i.sun.com with ESMTP id BT-MMP-14106441; Tue, 03 Mar 2009 18:43:34 +0000 (Z) Received: from mprox2.jpl.nasa.gov (mprox2.jpl.nasa.gov [137.78.160.141]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n23IhVxb020605; Tue, 03 Mar 2009 18:43:32 +0000 (GMT) Received: from dhcp-149-131-110.jpl.nasa.gov (dhcp-149-131-110.jpl.nasa.gov [128.149.131.110]) (authenticated bits=0) by mprox2.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id n23IhU73013081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 03 Mar 2009 10:43:30 -0800 Date: Tue, 03 Mar 2009 10:43:29 -0800 From: "Henry B. Hotz" Subject: Re: [kerberos-discuss] Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <49AD721D.3070301@Sun.COM> To: "Richard.Matthews@sun.com" Cc: Shawn Emery , Wyllys Ingersoll , "PSARC-ext@sun.com" Message-id: <9A48B973-4091-4930-8CCE-AE540823D2B7@jpl.nasa.gov> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Source-IP: dhcp-149-131-110.jpl.nasa.gov [128.149.131.110] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized X-Antispam: No, score=0.0/5.0, scanned in 0.113sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200901272114.n0RLE4kX009528@marduk.eng.sun.com> <4986BA46.20107@sun.com> <4989DB7B.2060500@Sun.COM> <49AD721D.3070301@Sun.COM> Status: RO Content-Length: 1366 Perhaps I said this before, but when you implement CCAPI, you also need to make sure that Java is able to use CCAPI ccaches. (Apple didn't do that. ;-) On Mar 3, 2009, at 10:08 AM, Rick Matthews wrote: > Shawn, > Correct me if I'm wrong, but I think you were going to do an > umbrella clarifying this case. > Wyllys, I think this should be in "waiting needs spec" until then. > Thanks > -- > On 02/04/09 12:16, Rick Matthews wrote: >> >> Shawn, >> I think there continues to be lack of understanding on this fast- >> track. Your suggestion of an umbrella >> case is a good one. I'd like to de-rail this case until that >> umbrella has occurred. >> -- >> Rick > -- > --------------------------------------------------------------------- > Rick Matthews email: Rick.Matthews@sun.com > Sun Microsystems, Inc. phone:+1(651) 554-1518 > 1270 Eagan Industrial Road phone(internal): 54418 > Suite 160 fax: +1(651) 554-1540 > Eagan, MN 55121-1231 USA main: +1(651) 554-1500 > --------------------------------------------------------------------- ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From Shawn.Emery@sun.com Tue Mar 3 14:18:13 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n23MICPt016304 for ; Tue, 3 Mar 2009 14:18:12 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n23MI4dp027588 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 3 Mar 2009 22:18:11 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFY00A0PBAB8Y00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 14:18:11 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFY001BVBAAY2D0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 14:18:10 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n23MIAaT029738 for ; Tue, 03 Mar 2009 22:18:10 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFY00C00B0N1W00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 15:18:09 -0700 (MST) Received: from [10.0.0.5] ([unknown] [67.190.47.79]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFY00DX0BA2AX80@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 15:18:03 -0700 (MST) Date: Tue, 03 Mar 2009 15:16:47 -0700 From: Shawn M Emery Subject: Re: [kerberos-discuss] Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <9A48B973-4091-4930-8CCE-AE540823D2B7@jpl.nasa.gov> Sender: Shawn.Emery@sun.com To: "Henry B. Hotz" Cc: "Richard.Matthews@sun.com" , Wyllys Ingersoll , "PSARC-ext@sun.com" Message-id: <49ADAC4F.4000605@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901272114.n0RLE4kX009528@marduk.eng.sun.com> <4986BA46.20107@sun.com> <4989DB7B.2060500@Sun.COM> <49AD721D.3070301@Sun.COM> <9A48B973-4091-4930-8CCE-AE540823D2B7@jpl.nasa.gov> User-Agent: Thunderbird 2.0.0.18 (X11/20081125) Status: RO Content-Length: 1587 Henry B. Hotz wrote: > Perhaps I said this before, but when you implement CCAPI, you also > need to make sure that Java is able to use CCAPI ccaches. (Apple > didn't do that. ;-) Yes, I've already contacted the Java security group and the contact there is aware of these changes and had said that they would support it. Shawn. -- > On Mar 3, 2009, at 10:08 AM, Rick Matthews wrote: > >> Shawn, >> Correct me if I'm wrong, but I think you were going to do an >> umbrella clarifying this case. >> Wyllys, I think this should be in "waiting needs spec" until then. >> Thanks >> -- >> On 02/04/09 12:16, Rick Matthews wrote: >>> >>> Shawn, >>> I think there continues to be lack of understanding on this >>> fast-track. Your suggestion of an umbrella >>> case is a good one. I'd like to de-rail this case until that >>> umbrella has occurred. >>> -- >>> Rick >> -- >> --------------------------------------------------------------------- >> Rick Matthews email: Rick.Matthews@sun.com >> Sun Microsystems, Inc. phone:+1(651) 554-1518 >> 1270 Eagan Industrial Road phone(internal): 54418 >> Suite 160 fax: +1(651) 554-1540 >> Eagan, MN 55121-1231 USA main: +1(651) 554-1500 >> --------------------------------------------------------------------- > > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu > > > From Nicolas.Williams@sun.com Tue Mar 3 14:20:04 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n23MK3km016924 for ; Tue, 3 Mar 2009 14:20:03 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n23MJt4g029089; Wed, 4 Mar 2009 06:19:58 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFY00611BD8IY00@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Mar 2009 14:19:56 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFY000M7BD71R80@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Mar 2009 14:19:55 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n23MArkE014599; Tue, 03 Mar 2009 16:10:53 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n23MArYU014598; Tue, 03 Mar 2009 16:10:53 -0600 (CST) Date: Tue, 03 Mar 2009 16:10:53 -0600 From: Nicolas Williams Subject: Re: [kerberos-discuss] Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <9A48B973-4091-4930-8CCE-AE540823D2B7@jpl.nasa.gov> To: "Henry B. Hotz" Cc: "Richard.Matthews@sun.com" , Shawn Emery , Wyllys Ingersoll , "PSARC-ext@sun.com" Message-id: <20090303221053.GC9992@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200901272114.n0RLE4kX009528@marduk.eng.sun.com> <4986BA46.20107@sun.com> <4989DB7B.2060500@Sun.COM> <49AD721D.3070301@Sun.COM> <9A48B973-4091-4930-8CCE-AE540823D2B7@jpl.nasa.gov> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 278 On Tue, Mar 03, 2009 at 10:43:29AM -0800, Henry B. Hotz wrote: > Perhaps I said this before, but when you implement CCAPI, you also > need to make sure that Java is able to use CCAPI ccaches. (Apple > didn't do that. ;-) Done, because JGSS now has a JNI bridge to libgss. From Shawn.Emery@sun.com Tue Mar 3 14:21:58 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n23MLvHv017641 for ; Tue, 3 Mar 2009 14:21:57 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n23MLgDh000068 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Mar 2009 06:21:56 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFY00805BGKAT00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 15:21:56 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFY001F1BGJFW80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 15:21:55 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n23MLtQp027967 for ; Tue, 03 Mar 2009 22:21:55 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFY00500B1WQI00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 15:21:55 -0700 (MST) Received: from [10.0.0.5] ([unknown] [67.190.47.79]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFY006ORBGHTXC0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Mar 2009 15:21:54 -0700 (MST) Date: Tue, 03 Mar 2009 15:20:38 -0700 From: Shawn M Emery Subject: Re: [kerberos-discuss] Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <49AD721D.3070301@Sun.COM> Sender: Shawn.Emery@sun.com To: Richard.Matthews@sun.com Cc: Wyllys Ingersoll , PSARC-ext@sun.com Message-id: <49ADAD36.6050100@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_a9TkR0vfFac8ATAK78VMKw)" X-PMX-Version: 5.4.1.325704 References: <200901272114.n0RLE4kX009528@marduk.eng.sun.com> <4986BA46.20107@sun.com> <4989DB7B.2060500@Sun.COM> <49AD721D.3070301@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081125) Status: RO Content-Length: 3667 This is a multi-part message in MIME format. --Boundary_(ID_a9TkR0vfFac8ATAK78VMKw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Rick Matthews wrote: > Shawn, > Correct me if I'm wrong, but I think you were going to do an > umbrella clarifying this case. Yes, I'll file the umbrella case after I finish the prototype. By then I will have a better understanding of resource requirements (memory foot print, restart timers, files accessed, and all the other details that were requested during the initial review). > Wyllys, I think this should be in "waiting needs spec" until then. Shawn. -- > On 02/04/09 12:16, Rick Matthews wrote: >> Shawn, >> I think there continues to be lack of understanding on this >> fast-track. Your suggestion of an umbrella >> case is a good one. I'd like to de-rail this case until that umbrella >> has occurred. >> -- >> Rick >> >> > -- > --------------------------------------------------------------------- > Rick Matthews email: Rick.Matthews@sun.com > Sun Microsystems, Inc. phone:+1(651) 554-1518 > 1270 Eagan Industrial Road phone(internal): 54418 > Suite 160 fax: +1(651) 554-1540 > Eagan, MN 55121-1231 USA main: +1(651) 554-1500 > --------------------------------------------------------------------- > --Boundary_(ID_a9TkR0vfFac8ATAK78VMKw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Rick Matthews wrote:
Shawn,
  Correct me if I'm wrong, but I think you were going to do an umbrella clarifying this case.

Yes, I'll file the umbrella case after I finish the prototype.  By then I will have a better understanding of resource requirements (memory foot print, restart timers, files accessed, and all the other details that were requested during the initial review).

Wyllys, I think this should be in "waiting needs spec" until then.
Shawn.
--
On 02/04/09 12:16, Rick Matthews wrote:
Shawn,
  I think there continues to be lack of understanding on this fast-track. Your suggestion of an umbrella
case is a good one. I'd like to de-rail this case until that umbrella has occurred.
--
Rick


-- 
---------------------------------------------------------------------
Rick Matthews                           email: Rick.Matthews@sun.com
Sun Microsystems, Inc.                  phone:+1(651) 554-1518
1270 Eagan Industrial Road              phone(internal): 54418
Suite 160                               fax:  +1(651) 554-1540
Eagan, MN 55121-1231 USA                main: +1(651) 554-1500		
---------------------------------------------------------------------

--Boundary_(ID_a9TkR0vfFac8ATAK78VMKw)-- From wyllys.ingersoll@sun.com Tue Mar 3 14:52:13 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n23MqCgl024925 for ; Tue, 3 Mar 2009 14:52:13 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n23MprBc020474; Tue, 3 Mar 2009 22:52:11 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFY00G05CUXTC00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Mar 2009 14:52:09 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFY00CX2CUWGR10@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Mar 2009 14:52:08 -0800 (PST) Received: from [10.7.251.182] (punchin-wyllys.SFBay.Sun.COM [10.7.251.182]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n23Mq7HZ409837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 03 Mar 2009 14:52:08 -0800 (PST) Date: Tue, 03 Mar 2009 17:52:06 -0500 From: Wyllys Ingersoll Subject: Re: [kerberos-discuss] Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009] In-reply-to: <49ADAD36.6050100@sun.com> To: Shawn M Emery Cc: Richard.Matthews@sun.com, PSARC-ext@sun.com Message-id: <49ADB496.8070309@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200901272114.n0RLE4kX009528@marduk.eng.sun.com> <4986BA46.20107@sun.com> <4989DB7B.2060500@Sun.COM> <49AD721D.3070301@Sun.COM> <49ADAD36.6050100@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090112) Status: RO Content-Length: 541 Shawn M Emery wrote: > Rick Matthews wrote: >> Shawn, >> Correct me if I'm wrong, but I think you were going to do an >> umbrella clarifying this case. > > Yes, I'll file the umbrella case after I finish the prototype. By then > I will have a better understanding of resource requirements (memory foot > print, restart timers, files accessed, and all the other details that > were requested during the initial review). > >> Wyllys, I think this should be in "waiting needs spec" until then. > Shawn. OK, I will update it. -Wyllys