From sacadmin Wed Apr 29 07:52:00 2009 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 n3TEq0AL023171; Wed, 29 Apr 2009 07:52:00 -0700 (PDT) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n3TEq02h023167; Wed, 29 Apr 2009 07:52:00 -0700 (PDT) Date: Wed, 29 Apr 2009 07:52:00 -0700 (PDT) From: "Garrett D'Amore - sun microsystems" Message-Id: <200904291452.n3TEq02h023167@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Cc: darren.moffat@sun.com, nicolas.williams@sun.com Subject: Credential Process Groups (CPGS) [PSARC/2009/271 OnePager] Status: RO Content-Length: 887 The case materials on this case are forthcoming very shortly. I hope to get an inception scheduled for next week (Wed 5/6/2009). I'm sponsoring this for Nicolas Williams, but I'm also expecting to be involved with the project at a deeper level as it is necessary for future work I'm doing to support Sun Ray audio. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Credential Process Groups (CPGS) 1.2. Name of Document Author/Supplier: Author: Nicolas Williams 1.3 Date of This Document: 29 April, 2009 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: OnePager 6.6. ARC Exposure: open From gdamore@SUN.COM Wed Apr 29 08:59:21 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 n3TFxKYc022532 for ; Wed, 29 Apr 2009 08:59:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3TFxG27017067 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 29 Apr 2009 08:59:20 -0700 (PDT) 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 <0KIV00M03DQLKE00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 29 Apr 2009 08:59:09 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIV00EWRDQL9N70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 29 Apr 2009 08:59:09 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3TFx95U016668 for ; Wed, 29 Apr 2009 08:59:09 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIV00L00DOEOJ00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 29 Apr 2009 08:59:09 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIV002ZLDQK7CC0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 29 Apr 2009 08:59:09 -0700 (PDT) Date: Wed, 29 Apr 2009 08:59:08 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/271 Credential Process Groups (CPGS) Sender: Garrett.Damore@SUN.COM To: PSARC-ext Message-id: <49F8794C.5060805@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 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1383 The inception materials are now available: gd78059@sac{36}> ls -la inception.materials/ total 90 drwxrwsr-x 3 gd78059 sac 9 Apr 29 08:45 . drwxrwsr-x 6 gd78059 sac 10 Apr 29 07:49 .. -rw-r--r-- 1 nw141292 sac 5130 Apr 29 08:54 20q.txt -rw-rw-r-- 1 gd78059 sac 1954 Apr 29 08:05 Linux-keyrings.txt -rw-rw-r-- 1 gd78059 sac 4057 Apr 29 07:58 Overview-terse.txt -rw-rw-r-- 1 gd78059 sac 19671 Apr 29 08:04 Overview.txt -rw-rw-r-- 1 gd78059 sac 2677 Apr 29 08:05 PAGs.txt -rw-r--r-- 1 nw141292 sac 383 Apr 29 08:05 bikeshed-paint.txt drwxrwsr-x 2 gd78059 sac 8 Apr 29 08:06 man gd78059@sac{37}> ls -la inception.materials/man/ total 113 drwxrwsr-x 2 gd78059 sac 8 Apr 29 08:06 . drwxrwsr-x 3 gd78059 sac 9 Apr 29 08:45 .. -rw-rw-r-- 1 gd78059 sac 10410 Apr 29 07:55 cpg_change.2 -rw-rw-r-- 1 gd78059 sac 2784 Apr 29 07:56 gss_acquire_cred_ucred.2 -rw-r--r-- 1 nw141292 sac 3060 Apr 29 08:06 gssd-diffs -rw-r--r-- 1 nw141292 sac 17658 Apr 29 08:06 pam_krb5-diffs -rw-r--r-- 1 nw141292 sac 5221 Apr 29 08:06 pam_unix_cred-diffs -rw-r--r-- 1 nw141292 sac 7443 Apr 29 08:06 ucred_get-diffs Secretary, can you please put us on the Agenda for Wednesday, May 6, 2009? Thank you. -- Garrett From Nicolas.Williams@sun.com Thu Apr 30 13:00:44 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 n3UK0hCF019504 for ; Thu, 30 Apr 2009 13:00:44 -0700 (PDT) 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 n3UK0TqS008280; Thu, 30 Apr 2009 21:00:41 +0100 (BST) 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 <0KIX0040XJL3TN00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 30 Apr 2009 13:00:39 -0700 (PDT) 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 <0KIX0030QJL1Q670@nwk-avmta-1.sfbay.Sun.COM>; Thu, 30 Apr 2009 13:00:38 -0700 (PDT) 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 n3UJwWs5021912; Thu, 30 Apr 2009 14:58:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3UJwWBh021911; Thu, 30 Apr 2009 14:58:32 -0500 (CDT) Date: Thu, 30 Apr 2009 14:58:32 -0500 From: Nicolas Williams Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <49F8794C.5060805@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <20090430195832.GM1500@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: <49F8794C.5060805@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: 387 On Wed, Apr 29, 2009 at 08:59:08AM -0700, Garrett D'Amore wrote: > The inception materials are now available: I've added two files to inception.materials/man: - cpg.1 A manpage for a new command. - pcred-diffs Diffs to pcred(1). The Overview.txt file refers to pcred changes but not to cpg(1); I'll leave it as is. Similarly, I'll leave the 20q.txt file as is. Nico -- From casper@holland.sun.com Mon May 4 08:37:51 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 n44Fbojd015756 for ; Mon, 4 May 2009 08:37:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n44Fboca045766 for <@sunmail2sca.sfbay.sun.com:psarc-ext@Sun.COM>; Mon, 4 May 2009 09:37:50 -0600 (MDT) 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 <0KJ40040DM31ZC00@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Mon, 04 May 2009 09:37:49 -0600 (MDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ400GE8M30X8D0@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Mon, 04 May 2009 09:37:48 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n44Fbk3o063175; Mon, 04 May 2009 16:37:46 +0100 (BST) Date: Mon, 04 May 2009 17:37:46 +0200 From: Casper.Dik@sun.com Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <20090504153147.GZ1500@Sun.COM> Sender: casper@holland.sun.com To: Nicolas Williams , psarc-ext@sun.com Message-id: <200905041537.n44Fbk3o063175@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49F8794C.5060805@sun.com> <20090430195832.GM1500@Sun.COM> <200905041138.n44BcQ5q050240@dm-holland-02.uk.sun.com> <20090504153147.GZ1500@Sun.COM> Status: RO Content-Length: 146 (Why was your reply not send to psarc*?) >I could always extend /proc, but it seems unnecessary. I think it is pretty much required. Casper From Nicolas.Williams@sun.com Mon May 4 08:49:49 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 n44FnnfI016093 for ; Mon, 4 May 2009 08:49:49 -0700 (PDT) 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 n44FnjcS000301; Mon, 4 May 2009 08:49:48 -0700 (PDT) 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 <0KJ400607MMZ3700@brm-avmta-1.central.sun.com>; Mon, 04 May 2009 09:49:47 -0600 (MDT) 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 <0KJ400GK1MMYWSA0@brm-avmta-1.central.sun.com>; Mon, 04 May 2009 09:49:46 -0600 (MDT) 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 n44FlZTr024794; Mon, 04 May 2009 10:47:35 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n44FlZW7024793; Mon, 04 May 2009 10:47:35 -0500 (CDT) Date: Mon, 04 May 2009 10:47:35 -0500 From: Nicolas Williams Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <200905041537.n44Fbk3o063175@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: psarc-ext@sun.com Message-id: <20090504154734.GA1500@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: <49F8794C.5060805@sun.com> <20090430195832.GM1500@Sun.COM> <200905041138.n44BcQ5q050240@dm-holland-02.uk.sun.com> <20090504153147.GZ1500@Sun.COM> <200905041537.n44Fbk3o063175@dm-holland-02.uk.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: 1004 On Mon, May 04, 2009 at 05:37:46PM +0200, Casper.Dik@Sun.COM wrote: > > (Why was your reply not send to psarc*?) Your questions weren't sent to PSARC, so I didn't send my reply to PSARC either. > >I could always extend /proc, but it seems unnecessary. > > I think it is pretty much required. The missing context, for PSARC readers, is that Casper says that to modify ptools one ought to modify /proc as well. In this case the new system calls provide enough observability that /proc changes would be redundant, but modifying pcred would still be useful for observability, and anyways, holding a proc(4) handle to a process to prevent PID reuse while examining it is also useful. If there's a hard and fast rule that ptools cannot use facilities outside proc(4) for observing targets then we could easily extend proc(4) to make CPG information available through proc(4). But as I said, given that the CPG syscalls provide sufficient observability it seems unnecessary to extend proc(4). Nico -- From casper@holland.sun.com Mon May 4 10:27: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 n44HR4pp019876 for ; Mon, 4 May 2009 10:27:04 -0700 (PDT) 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 n44HR1EP044347 for <@sunmail2sca.sfbay.sun.com:psarc-ext@Sun.COM>; Mon, 4 May 2009 11:27:04 -0600 (MDT) 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 <0KJ400021R53B500@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Mon, 04 May 2009 10:27:03 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ400BA3R51FU60@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Mon, 04 May 2009 10:27:02 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n44HR0e7036430; Mon, 04 May 2009 18:27:00 +0100 (BST) Date: Mon, 04 May 2009 19:27:00 +0200 From: Casper.Dik@sun.com Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <20090504154734.GA1500@Sun.COM> Sender: casper@holland.sun.com To: Nicolas Williams Cc: psarc-ext@sun.com Message-id: <200905041727.n44HR0e7036430@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49F8794C.5060805@sun.com> <20090430195832.GM1500@Sun.COM> <200905041138.n44BcQ5q050240@dm-holland-02.uk.sun.com> <20090504153147.GZ1500@Sun.COM> <200905041537.n44Fbk3o063175@dm-holland-02.uk.sun.com> <20090504154734.GA1500@Sun.COM> Status: RO Content-Length: 959 >On Mon, May 04, 2009 at 05:37:46PM +0200, Casper.Dik@Sun.COM wrote: >> >> (Why was your reply not send to psarc*?) > >Your questions weren't sent to PSARC, so I didn't send my reply to PSARC >either. Oops; my bad. Here's my email (for the record) >On Wed, Apr 29, 2009 at 08:59:08AM -0700, Garrett D'Amore wrote: >> The inception materials are now available: > >I've added two files to inception.materials/man: > > - cpg.1 > > A manpage for a new command. > > > - pcred-diffs > > Diffs to pcred(1). > >The Overview.txt file refers to pcred changes but not to cpg(1); I'll >leave it as is. Similarly, I'll leave the 20q.txt file as is. Where are the changes to /proc? You cannot modify "ptools" without having the properties available through /proc. How are the CPGs recorded in a core dump? How are the CPGs shown through pcred? Does that work in a core dump? What happens when a user su(1)s to root and then starts a daemon? Casper From Nicolas.Williams@sun.com Mon May 4 11:26:06 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 n44IQ5DQ022075 for ; Mon, 4 May 2009 11:26:06 -0700 (PDT) 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 n44IQ0sl014168; Tue, 5 May 2009 02:26:03 +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 <0KJ400L0DTVEUD00@brm-avmta-1.central.sun.com>; Mon, 04 May 2009 12:26:02 -0600 (MDT) 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 <0KJ400GQPTVDIB80@brm-avmta-1.central.sun.com>; Mon, 04 May 2009 12:26:02 -0600 (MDT) 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 n44INtKC024993; Mon, 04 May 2009 13:23:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n44INtkA024992; Mon, 04 May 2009 13:23:55 -0500 (CDT) Date: Mon, 04 May 2009 13:23:55 -0500 From: Nicolas Williams Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <200905041727.n44HR0e7036430@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: psarc-ext@sun.com Message-id: <20090504182354.GN1500@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: <49F8794C.5060805@sun.com> <20090430195832.GM1500@Sun.COM> <200905041138.n44BcQ5q050240@dm-holland-02.uk.sun.com> <20090504153147.GZ1500@Sun.COM> <200905041537.n44Fbk3o063175@dm-holland-02.uk.sun.com> <20090504154734.GA1500@Sun.COM> <200905041727.n44HR0e7036430@dm-holland-02.uk.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: 2583 On Mon, May 04, 2009 at 07:27:00PM +0200, Casper.Dik@Sun.COM wrote: > Here's my email (for the record) Thanks. > Where are the changes to /proc? > > You cannot modify "ptools" without having the properties available through > /proc. My answers to these two questions are already in the case record. > How are the CPGs recorded in a core dump? Ah, good point. I'll go figure that out. At first glance it looks like CPGs would appear in core files in the form of an "ELF note" (see elfnote(), corenote(), and Pfgrab_core()), probably in the form of an integer indicating how many CPGs, another indicating the size of CPG type names, another indicating the size of CPG user data, then an array of fixed sized {CPG ID, type name, user data}. > How are the CPGs shown through pcred? Does that work in a core dump? I don't have code for this yet, but I'm thinking it'd be something like: % pcred $$ 17350: e/r/suid=142292 e/r/sgid=10 groups: 10 30303 CPG: krb5 123456789 [] CPG: audio 123456790 [] Yes, this would work on core files (through libproc, which will have to know about this). > What happens when a user su(1)s to root and then starts a daemon? First of all they should use SMF. This applies in too many cases already (think of resource controls, TX, ...). It's already the case that su inherits some things that sometimes it ought not (e.g., environment variables, unless one does su -). Passing too many things of some kinds and not enough of others is a problem. I'm not sure that I have a good answer (though perhaps su - should always clear all CPGs that can be cleared in the new process). Second, one of the CPG type semantics flags is whether a CPG should be changed on su(1) or not. So one should think carefully when picking a new CPG type's semantics. Third, for CPGs that we normally want inheritted through su(1) we might want a PAM module to change them anyways when doing becoming root. But I'm not convinced. I think the right thing to do is to not start daemons by hand. Nico -- From boyd-adamson@usa.net Mon May 4 23:40:14 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 n456eDdU002053 for ; Mon, 4 May 2009 23:40:13 -0700 (PDT) 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 n456e8rS059417; Tue, 5 May 2009 00:40:11 -0600 (MDT) 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 <0KJ500J11RUXSQ00@nwk-avmta-2.sfbay.sun.com>; Mon, 04 May 2009 23:40:09 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ500ARJRUVL760@nwk-avmta-2.sfbay.sun.com>; Mon, 04 May 2009 23:40:07 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n456e3h6013698; Tue, 05 May 2009 06:40:07 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-1626594; Tue, 05 May 2009 06:40:03 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-49981390; Tue, 05 May 2009 06:40:01 +0000 (Z) Received: from ipmail04.adl2.internode.on.net ([203.16.214.57] [203.16.214.57]) by relay1i.sun.com with ESMTP id BT-MMP-45277566; Tue, 05 May 2009 06:40:01 +0000 (Z) Received: from boydadamson.com (HELO maelstrom.tactio.lan) ([150.101.157.138]) by ipmail04.adl2.internode.on.net with ESMTP; Tue, 05 May 2009 16:06:39 +0930 Received: from maelstrom.tactio.lan ([10.11.12.4] helo=maelstrom) by maelstrom.tactio.lan with esmtp (Exim 4.69) (envelope-from ) id 1M1EGa-0002Q7-N1; Tue, 05 May 2009 16:36:36 +1000 Date: Tue, 05 May 2009 16:36:36 +1000 From: Boyd Adamson Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <20090504182354.GN1500@Sun.COM> To: Nicolas Williams Cc: Casper.Dik@sun.com, psarc-ext@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 0.153sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <49F8794C.5060805@sun.com> <20090430195832.GM1500@Sun.COM> <200905041138.n44BcQ5q050240@dm-holland-02.uk.sun.com> <20090504153147.GZ1500@Sun.COM> <200905041537.n44Fbk3o063175@dm-holland-02.uk.sun.com> <20090504154734.GA1500@Sun.COM> <200905041727.n44HR0e7036430@dm-holland-02.uk.sun.com> <20090504182354.GN1500@Sun.COM> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (usg-unix-v) Status: RO Content-Length: 2850 I don't see any mention in the case materials of new fields for ps. Personally, I'd really like to see something like -o cpg Nicolas Williams writes: > On Mon, May 04, 2009 at 07:27:00PM +0200, Casper.Dik@Sun.COM wrote: >> Here's my email (for the record) > > Thanks. > >> Where are the changes to /proc? >> >> You cannot modify "ptools" without having the properties available through >> /proc. > > My answers to these two questions are already in the case record. > >> How are the CPGs recorded in a core dump? > > Ah, good point. I'll go figure that out. > > At first glance it looks like CPGs would appear in core files in the > form of an "ELF note" (see elfnote(), corenote(), and Pfgrab_core()), > probably in the form of an integer indicating how many CPGs, another > indicating the size of CPG type names, another indicating the size of > CPG user data, then an array of fixed sized {CPG ID, type name, user > data}. > >> How are the CPGs shown through pcred? Does that work in a core dump? > > I don't have code for this yet, but I'm thinking it'd be something like: > > % pcred $$ > 17350: e/r/suid=142292 e/r/sgid=10 > groups: 10 30303 > CPG: krb5 123456789 [] > CPG: audio 123456790 [] > > Yes, this would work on core files (through libproc, which will have to > know about this). > >> What happens when a user su(1)s to root and then starts a daemon? > > First of all they should use SMF. This applies in too many cases > already (think of resource controls, TX, ...). > > It's already the case that su inherits some things that sometimes it > ought not (e.g., environment variables, unless one does su -). Passing > too many things of some kinds and not enough of others is a problem. > > I'm not sure that I have a good answer (though perhaps su - should > always clear all CPGs that can be cleared in the new process). > > Second, one of the CPG type semantics flags is whether a CPG should be > changed on su(1) or not. So one should think carefully when picking a > new CPG type's semantics. > > Third, for CPGs that we normally want inheritted through su(1) we might > want a PAM module to change them anyways when doing becoming root. But > I'm not convinced. I think the right thing to do is to not start > daemons by hand. > > Nico From Nicolas.Williams@Sun.COM Tue May 5 08:43:10 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 n45FhAJc004921 for ; Tue, 5 May 2009 08:43:10 -0700 (PDT) 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 n45Fh7G2019631; Tue, 5 May 2009 08:43:08 -0700 (PDT) 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 <0KJ600C07GZVCD00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 May 2009 08:43:07 -0700 (PDT) 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 <0KJ6002JNGZVX660@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 May 2009 08:43:07 -0700 (PDT) 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 n45Fevdg025386; Tue, 05 May 2009 10:40:57 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n45FevNO025385; Tue, 05 May 2009 10:40:57 -0500 (CDT) Date: Tue, 05 May 2009 10:40:56 -0500 From: Nicolas Williams Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: To: Boyd Adamson Cc: Casper.Dik@Sun.COM, psarc-ext@Sun.COM Message-id: <20090505154056.GV1500@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: <49F8794C.5060805@sun.com> <20090430195832.GM1500@Sun.COM> <200905041138.n44BcQ5q050240@dm-holland-02.uk.sun.com> <20090504153147.GZ1500@Sun.COM> <200905041537.n44Fbk3o063175@dm-holland-02.uk.sun.com> <20090504154734.GA1500@Sun.COM> <200905041727.n44HR0e7036430@dm-holland-02.uk.sun.com> <20090504182354.GN1500@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: 396 On Tue, May 05, 2009 at 04:36:36PM +1000, Boyd Adamson wrote: > I don't see any mention in the case materials of new fields for ps. > > Personally, I'd really like to see something like -o cpg The problem with ps(1) is that it produces column-oriented output, and it has to prevent the columns from running on, into each other or the right margin. Displaying CPGs would be difficult. Advice? From gdamore@sun.com Tue May 5 08:54:48 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 n45Fslgm005501 for ; Tue, 5 May 2009 08:54:47 -0700 (PDT) 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 n45FrVIu014062 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 5 May 2009 16:54:46 +0100 (BST) 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 <0KJ600D01HIXLW00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 05 May 2009 08:54:33 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ60025RHIVX570@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 05 May 2009 08:54:33 -0700 (PDT) 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 n45FsVRH013377 for ; Tue, 05 May 2009 08:54:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ600K00H6UQN00@fe-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 05 May 2009 08:54:31 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ6005MVHIN1Z80@fe-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 05 May 2009 08:54:25 -0700 (PDT) Date: Tue, 05 May 2009 08:54:23 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <20090505154056.GV1500@Sun.COM> Sender: Garrett.Damore@sun.com To: Nicolas Williams Cc: Boyd Adamson , Casper.Dik@sun.com, psarc-ext@sun.com Message-id: <4A00612F.3040007@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49F8794C.5060805@sun.com> <20090430195832.GM1500@Sun.COM> <200905041138.n44BcQ5q050240@dm-holland-02.uk.sun.com> <20090504153147.GZ1500@Sun.COM> <200905041537.n44Fbk3o063175@dm-holland-02.uk.sun.com> <20090504154734.GA1500@Sun.COM> <200905041727.n44HR0e7036430@dm-holland-02.uk.sun.com> <20090504182354.GN1500@Sun.COM> <20090505154056.GV1500@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1035 Nicolas Williams wrote: > On Tue, May 05, 2009 at 04:36:36PM +1000, Boyd Adamson wrote: > >> I don't see any mention in the case materials of new fields for ps. >> >> Personally, I'd really like to see something like -o cpg >> > > The problem with ps(1) is that it produces column-oriented output, and > it has to prevent the columns from running on, into each other or the > right margin. Displaying CPGs would be difficult. Advice? > I concur with Nico here... I think that displaying CPGs would be "difficult" here. "ps" is not intended to be able to display all information about a process... although it does print a *lot* of information. For example, you can not display saved, effective, and real UIDs and GIDs associated with a process, with "ps". For that kind of more complete information, you need "pcred". While "ps" does display the single most relevant (current) value for the process, it would be harder to do this for CPGs because there is no CPG that is more relevant than any other. -- Garrett From boyd-adamson@usa.net Tue May 5 15:30:04 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 n45MU40e013760 for ; Tue, 5 May 2009 15:30:04 -0700 (PDT) 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 n45MU2t8011941; Tue, 5 May 2009 15:30:02 -0700 (PDT) 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 <0KJ600G01ZU1R700@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 May 2009 15:30:01 -0700 (PDT) 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 <0KJ6005PFZTZ4HA0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 May 2009 15:29:59 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n45MMUKu020421; Tue, 05 May 2009 22:29:58 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay15i.sun.com with ESMTP id BT-MMP-1665052; Tue, 05 May 2009 22:29:58 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-52702753; Tue, 05 May 2009 22:29:58 +0000 (Z) Received: from ipmail04.adl2.internode.on.net ([203.16.214.57] [203.16.214.57]) by relay1i.sun.com with ESMTP id BT-MMP-2238195; Tue, 05 May 2009 22:29:54 +0000 (Z) Received: from boydadamson.com (HELO maelstrom.tactio.lan) ([150.101.157.138]) by ipmail04.adl2.internode.on.net with ESMTP; Wed, 06 May 2009 07:59:48 +0930 Received: from maelstrom.tactio.lan ([10.11.12.4] helo=[127.0.0.1]) by maelstrom.tactio.lan with esmtp (Exim 4.69) (envelope-from ) id 1M1T90-0000By-77; Wed, 06 May 2009 08:29:46 +1000 Date: Wed, 06 May 2009 08:29:46 +1000 From: Boyd Adamson Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <4A00612F.3040007@sun.com> To: "Garrett D'Amore" Cc: Nicolas Williams , Casper.Dik@sun.com, psarc-ext@sun.com Message-id: <57FC2053-3CEF-47AF-AA18-B87E3DBAF093@usa.net> 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-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUFAMdaAEqWZZ2K/2dsb2JhbACBUM8ThAEF X-IronPort-AV: E=Sophos;i="4.40,299,1238941800"; d="scan'208";a="367520492" X-Antispam: No, score=0.0/5.0, scanned in 0.130sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <49F8794C.5060805@sun.com> <20090430195832.GM1500@Sun.COM> <200905041138.n44BcQ5q050240@dm-holland-02.uk.sun.com> <20090504153147.GZ1500@Sun.COM> <200905041537.n44Fbk3o063175@dm-holland-02.uk.sun.com> <20090504154734.GA1500@Sun.COM> <200905041727.n44HR0e7036430@dm-holland-02.uk.sun.com> <20090504182354.GN1500@Sun.COM> <20090505154056.GV1500@Sun.COM> <4A00612F.3040007@sun.com> Status: RO Content-Length: 1297 On 06/05/2009, at 1:54 AM, Garrett D'Amore wrote: > Nicolas Williams wrote: >> On Tue, May 05, 2009 at 04:36:36PM +1000, Boyd Adamson wrote: >> >>> I don't see any mention in the case materials of new fields for ps. >>> >>> Personally, I'd really like to see something like -o cpg >>> >> >> The problem with ps(1) is that it produces column-oriented output, >> and >> it has to prevent the columns from running on, into each other or the >> right margin. Displaying CPGs would be difficult. Advice? >> > I concur with Nico here... I think that displaying CPGs would be > "difficult" here. "ps" is not intended to be able to display all > information about a process... although it does print a *lot* of > information. For example, you can not display saved, effective, and > real UIDs and GIDs associated with a process, with "ps". For that > kind of more complete information, you need "pcred". While "ps" does > display the single most relevant (current) value for the process, it > would be harder to do this for CPGs because there is no CPG that is > more relevant than any other. I can see the problem. I can't immediately think of a solution, but an option that selects only processes that belong to a particular CPG (a la -p, -z, -t) may be useful and not too hard From William.Fiveash@sun.com Tue May 5 16:23:36 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 n45NNZ9W012399 for ; Tue, 5 May 2009 16:23:35 -0700 (PDT) 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 n45NNNr5011158; Wed, 6 May 2009 00:23:33 +0100 (BST) 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 <0KJ700E012B6R400@brm-avmta-1.central.sun.com>; Tue, 05 May 2009 17:23:30 -0600 (MDT) Received: from alton.central.sun.com ([129.153.128.101]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ700M602B5WJC0@brm-avmta-1.central.sun.com>; Tue, 05 May 2009 17:23:30 -0600 (MDT) Received: from alton.central.sun.com (localhost [127.0.0.1]) by alton.central.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n45NNTcZ001233; Tue, 05 May 2009 18:23:29 -0500 (CDT) Received: (from willf@localhost) by alton.central.sun.com (8.14.3+Sun/8.14.2/Submit) id n45NNTRO001232; Tue, 05 May 2009 18:23:29 -0500 (CDT) Date: Tue, 05 May 2009 18:23:29 -0500 From: Will Fiveash Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) To: Nicolas Williams Cc: psarc-ext@sun.com Message-id: <20090505232329.GA1194@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 User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 843 In http://sac.sfbay.sun.com/Archives/CaseLog/arc/PSARC/2009/271/inception.materials/Overview-terse.txt there is: Architecture: CPG membership is driven primarily by PAM modules and applications: ... - svc:/system/cpg/krb5:default registers the "krb5" CPG type and runs a daemon to kdestroy Kerberos V credentials when the last reference to a CPG vanishes. How does this interact with svc:/network/security/ktkt_warn? Seems to me that there should be one service tending to the needs of the krb5 related ccache. Perhaps the function of ktkt_warn can be folded into svc:/system/cpg/krb5? -- Will Fiveash Sun Microsystems Office x64079/512-401-1079 Austin, TX, 78727 (TZ=CST6CDT), USA Internal Solaris Kerberos/GSS/SASL website: http://kerberos.sfbay.sun.com http://opensolaris.org/os/project/kerberos/ From gdamore@sun.com Tue May 5 21:15: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 n464FTbg013760 for ; Tue, 5 May 2009 21:15:29 -0700 (PDT) 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 n464FSfb025525 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 5 May 2009 21:15:29 -0700 (PDT) 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 <0KJ70001BFTTK400@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 05 May 2009 22:15:29 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ700MTMFTSPI00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 05 May 2009 22:15:28 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n464FRYo019934 for ; Tue, 05 May 2009 21:15:27 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ700900FPK0600@fe-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 05 May 2009 21:15:27 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ700CJOFTNMU70@fe-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 05 May 2009 21:15:25 -0700 (PDT) Date: Tue, 05 May 2009 21:15:23 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <57FC2053-3CEF-47AF-AA18-B87E3DBAF093@usa.net> Sender: Garrett.Damore@sun.com To: Boyd Adamson Cc: Nicolas Williams , Casper.Dik@sun.com, psarc-ext@sun.com Message-id: <4A010EDB.4020903@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: <49F8794C.5060805@sun.com> <20090430195832.GM1500@Sun.COM> <200905041138.n44BcQ5q050240@dm-holland-02.uk.sun.com> <20090504153147.GZ1500@Sun.COM> <200905041537.n44Fbk3o063175@dm-holland-02.uk.sun.com> <20090504154734.GA1500@Sun.COM> <200905041727.n44HR0e7036430@dm-holland-02.uk.sun.com> <20090504182354.GN1500@Sun.COM> <20090505154056.GV1500@Sun.COM> <4A00612F.3040007@sun.com> <57FC2053-3CEF-47AF-AA18-B87E3DBAF093@usa.net> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1358 Boyd Adamson wrote: > On 06/05/2009, at 1:54 AM, Garrett D'Amore wrote: >> Nicolas Williams wrote: >>> On Tue, May 05, 2009 at 04:36:36PM +1000, Boyd Adamson wrote: >>> >>>> I don't see any mention in the case materials of new fields for ps. >>>> >>>> Personally, I'd really like to see something like -o cpg >>>> >>> >>> The problem with ps(1) is that it produces column-oriented output, and >>> it has to prevent the columns from running on, into each other or the >>> right margin. Displaying CPGs would be difficult. Advice? >>> >> I concur with Nico here... I think that displaying CPGs would be >> "difficult" here. "ps" is not intended to be able to display all >> information about a process... although it does print a *lot* of >> information. For example, you can not display saved, effective, and >> real UIDs and GIDs associated with a process, with "ps". For that >> kind of more complete information, you need "pcred". While "ps" does >> display the single most relevant (current) value for the process, it >> would be harder to do this for CPGs because there is no CPG that is >> more relevant than any other. > > I can see the problem. I can't immediately think of a solution, but an > option that selects only processes that belong to a particular CPG (a > la -p, -z, -t) may be useful and not too hard Agreed. -- Garrett From gdamore@sun.com Tue May 5 21:35:33 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 n464ZW6A013823 for ; Tue, 5 May 2009 21:35:32 -0700 (PDT) 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 n464ZFac000316 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 6 May 2009 12:35:31 +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 <0KJ700501GR51V00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 05 May 2009 21:35:29 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ7000E2GR48I40@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 05 May 2009 21:35:28 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n464ZS65020775 for ; Tue, 05 May 2009 21:35:28 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ700M00GNH3R00@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 05 May 2009 21:35:28 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ700GHUGR3CB20@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 05 May 2009 21:35:28 -0700 (PDT) Date: Tue, 05 May 2009 21:35:27 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <20090505232329.GA1194@sun.com> Sender: Garrett.Damore@sun.com To: Will Fiveash Cc: Nicolas Williams , psarc-ext@sun.com Message-id: <4A01138F.5020104@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: <20090505232329.GA1194@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 780 Will Fiveash wrote: > In > http://sac.sfbay.sun.com/Archives/CaseLog/arc/PSARC/2009/271/inception.materials/Overview-terse.txt > there is: > > Architecture: > > CPG membership is driven primarily by PAM modules and applications: > > ... > > - svc:/system/cpg/krb5:default registers the "krb5" CPG type and runs a > daemon to kdestroy Kerberos V credentials when the last reference to > a CPG vanishes. > > How does this interact with svc:/network/security/ktkt_warn? Seems to > me that there should be one service tending to the needs of the krb5 > related ccache. Perhaps the function of ktkt_warn can be folded into > svc:/system/cpg/krb5? > Seems like a reasonable idea, but I'm not familiar enough with kerberos itself to comment on this. Nico? - Garrett From MAILER-DAEMON Tue May 5 22:29:23 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 n465TMQw015179 for ; Tue, 5 May 2009 22:29:23 -0700 (PDT) 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 n465TIpq026145; Wed, 6 May 2009 06:29:20 +0100 (BST) 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 <0KJ700801J8VNA00@nwk-avmta-2.sfbay.sun.com>; Tue, 05 May 2009 22:29:19 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ7000YHJ8V8D70@nwk-avmta-2.sfbay.sun.com>; Tue, 05 May 2009 22:29:19 -0700 (PDT) Received: from rosseau (rosseau.SFBay.Sun.COM [129.146.228.252]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n465TIGj333971; Tue, 05 May 2009 22:29:18 -0700 (PDT) Date: Tue, 05 May 2009 22:29:52 -0700 From: Stephen Hahn Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <49F8794C.5060805@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <20090506052949.GA1384@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. 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: <49F8794C.5060805@sun.com> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 2282 Interesting proposal. Of the bikeshed options, I like the ones with "credential" in them over those mentioning "session" or "process group" (since there are no process collectives that allow pre-existing processes to join them). Some questions: 1. What are the default registered CPG types on a newly booted system? (Are there CPG types created by the kernel prior to the creation of init(1M)?) 1'. If the kernel does create such types, how do they participate in the "resource release at empty" operation? 2. Why 64-bit IDs, and not reuse of id_t and idtype_t? (Unusual for a process collective.) 3. What is the complete list of system calls that cause a CPG to change its settings? For instance, should setuid(2) or setppriv(2) calls also have CPG_F_* flags? 4. There's no new privilege needed for CPG type registration or removal? What privilege is required? 5. Do you expect the behaviour of a cpg_type_unreg() call to be blocking--destroying all CPGs of that type--or merely allow those CPGs to linger until all processes have exited. What happens to CPGs with door calls in the _unreg() case? 6. It would be helpful to see the Boomer example explained a bit, if any preliminary sketch is available. (My feeling is that there's a lot of public mechanism for one consumer.) 7. Usually the zone/project/task/process resource controls need to be transferred in the attributes of the work unit of whatever subsystem is taking the request out of process context but, if you've worked out more about subsuming those attributes, I'd be interested in seeing the details. 8. Could the project team comment when they expect a new feature should introduce a CPG type, rather than a process privilege? It might also be useful to understand how CPGs might be used to implement a concept like a security label, as in classic Trusted Solaris? I suppose I'm looking for early advice about how to design using this feature. (For instance, if the answer to 1/1' is "no", then does that imply kernel features must introduce privileges?) Thanks Stephen -- sch@sun.com http://blogs.sun.com/sch/ From gdamore@sun.com Tue May 5 22:39:12 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 n465dCSq015268 for ; Tue, 5 May 2009 22:39:12 -0700 (PDT) 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 n465d36C018942 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 5 May 2009 22:39:11 -0700 (PDT) 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 <0KJ70090HJP9R300@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 05 May 2009 23:39:09 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ700MF3JP8PGA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 05 May 2009 23:39:08 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n465d8eN022904 for ; Tue, 05 May 2009 22:39:08 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ700200JG0HN00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 05 May 2009 22:39:08 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ700A03JP76Q60@fe-sfbay-09.sun.com>; Tue, 05 May 2009 22:39:08 -0700 (PDT) Date: Tue, 05 May 2009 22:39:07 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <20090506052949.GA1384@eng.sun.com> Sender: Garrett.Damore@sun.com To: Stephen Hahn Cc: PSARC-ext Message-id: <4A01227B.9000908@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: <49F8794C.5060805@sun.com> <20090506052949.GA1384@eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1661 Stephen Hahn wrote: > > 6. It would be helpful to see the Boomer example explained a bit, if > any preliminary sketch is available. (My feeling is that there's > a lot of public mechanism for one consumer.) > Boomer 's use of this will be for Sun Ray audio. For Sun Ray audio, we need to know -- in the context of a file opened against "/dev/mixer" or "/dev/dsp", what the Sun Ray session is. At the moment, we think any reasonably unique value (unique on the host at the time of creation) is sufficient. This allows us to work around the fact that OSS applications don't have a standard "AUDIODEV" environment variable that can be overridden. It also allows us to avoid creating "scratch" device nodes in the /tmp file system. The pattern would be something like this: * pam_sunray (or somesuch) creates a CPG for the Sun Ray session on authentication * open("/dev/dsp") or open("/dev/audio") retrieves the CPG, and notices that the session is associated with a Sun Ray session, and sets up some in kernel mapping between the CPG and a userland process that routes audio to the actual device. This state would probably be tracked on a cloned minor node allocated dynamically at open() time. (Standard Solaris cloning semantics.) * All future ops on the cloned minor now are referenced against the specific Sun Ray session logical device * At close() time we can tear down the mapping (possibly using some kind of reference counting) * At logout, the pam module would free the CPG state, and toss any stale mappings. I don't know if that is clear enough, but I hope it conveys the general idea. - Garrett From edward.pilatowicz@sun.com Wed May 6 00:02:48 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 n4672l0D011054 for ; Wed, 6 May 2009 00:02:47 -0700 (PDT) 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 n4672klJ016814; Wed, 6 May 2009 00:02:47 -0700 (PDT) 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 <0KJ700I0BNKMSY00@brm-avmta-1.central.sun.com>; Wed, 06 May 2009 01:02:46 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ700EWBNKM9Y10@brm-avmta-1.central.sun.com>; Wed, 06 May 2009 01:02:46 -0600 (MDT) Received: from eng.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4672j4j054192; Wed, 06 May 2009 00:02:45 -0700 (PDT) Date: Wed, 06 May 2009 00:02:45 -0700 From: Edward Pilatowicz Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <20090430195832.GM1500@Sun.COM> To: Nicolas Williams Cc: "Garrett D'Amore" , PSARC-ext Message-id: <20090506070244.GB329918@eng.sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_UMvGjFOiSJU1TwEoD+6ghg)" Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <49F8794C.5060805@sun.com> <20090430195832.GM1500@Sun.COM> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 6269 --Boundary_(ID_UMvGjFOiSJU1TwEoD+6ghg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline hey nicolas, so i started reviewing these materials from a zones integration perspective, but while reading them i realized that i had a lot of general questions as well wrt how this functionality would actually work. i've attached my questions, broken into two sections. first is the general questions (to help me understand this stuff better) and second is the zones related questions. thanks ed On Thu, Apr 30, 2009 at 02:58:32PM -0500, Nicolas Williams wrote: > On Wed, Apr 29, 2009 at 08:59:08AM -0700, Garrett D'Amore wrote: > > The inception materials are now available: > > I've added two files to inception.materials/man: > > - cpg.1 > > A manpage for a new command. > > > - pcred-diffs > > Diffs to pcred(1). > > The Overview.txt file refers to pcred changes but not to cpg(1); I'll > leave it as is. Similarly, I'll leave the 20q.txt file as is. > > Nico > -- --Boundary_(ID_UMvGjFOiSJU1TwEoD+6ghg) Content-type: text/plain; NAME=c.txt; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=c.txt ------------------------------------------------------------------------------- general questions: - you repeatedly state that CPGs are associated with login sessions. please define a login session in the CPG context and provide examples. you also mention that CPGs will help with obtaining credentials for cron jobs, which specifically don't have a login session (as i understand login sessions), so please explain how this works. - you mention that CPGs are bound to credentials (there seems to be a 1:1 mapping), but in my gdm login session, different xterms have different cred_t pointers. so will different xterms have different CPGs? (once again, perhaps this confusion results from my lack of understanding of how "login sessions" are defined wrt CPGs.) - group membership is represented in cred_t. does this impact cred_t comparisons? (ala crcmp()). - why must CPGs IDs be unique (since boot)? - why isn't ps(1) being modified to display the CPGs ID? - is the CPG door upcall mechanism used for anything other than a notification for when a CPG group becomes empty? (i'm worried that perhaps we're adopting the linux behaviour of having the kernel spawn processes to prompt the user for information.) - given that CPGs are associated with credentials, how could they replace process project(4)s and tasks, which can contain process with different credentials? - you mention encoding ssh agent information in CPGs. afaik, the current problem with ssh agent environment variables is that if someone connects to a machine via ssh, starts the ssh agent, then logs into the machine again via ssh, the second login session won't know about the agent started by the first session. how can CPGs solve this problem? - you mention that on linux, a process may manipulate it's parents PAGs. will this be possible for solaris? (i'm hoping the answer is no.) if it's yes, could you please site me some examples of subsystems where a subprocess is allowed to modify it's parents properties? (i can think of examples where one process can modify another via /proc or some -p type option, but these are all subject to priv checks and not just blindly permitted because there is some kind of causal relationship between the two processes.) - cpg_chown() and cpg_chown_byid() please define a CPG owner. (do CPGs have an owner that is separate from the cred_t associated with the CPG?) when would you ever want to change the ownership of a CPG? what happens to all the processes bound to that CPG when it's ownership changes? - it seems like there are a lot of CPG data modifier flags. are CPG_S_SESSION_PRIVATE_DATA and CPG_S_SENSITIVE_DATA really useful? they require proc_session and proc_info respectively, and both these privs are included in the basic set, so who are you actually protecting this "private/sensitive" data from? - a 64-byte user data field for a CPG seems small. how did you decide on this size? is there any reason the size isn't specified when the CPG type is created? - why bother with _CONFIG_NCPGROUPS? (it seems like it would be more usefull to have a sysconf variable for the size of the user data if you plan to keep it as a fixed size. using sysconf for this instead of a define would allow for easier increases of the value in the future.) ------------------------------------------------------------------------------- zones questions: - this worries me: - New CPG types can be registered early at boot time in the global zone why isn't the CPG type namespace unique across zones and why can't zones create their own CPG types? why can CPGs only be created early in boot? please define early. the cpg(1) command seems to be able to create and destroy cpg types. will this command fail if it's run after the system is booted? if CPG types can be created after boot, are there any resource limits on CPG type creation? are there any privs to control CPG type creation? - if CPGs are used by things like kerberos, and kerberos is not enabled in the global zone, but it is enabled for a non-global, how will the kerberos CPG type be registered? (this also applies to other services that may use CPGs in the future, like ssh, etc.) - this also worries me: CPG types will be registered in the global zone by an SMF service per-CPG type. These services will also be able to register a door (in the global zone and in non-global zones) that will receive upcalls indicating CPG emptiness events. so global zone services are registering doors within zones? doors are bound to paths. so how do these services deal with zones that are not mounted, attached, installed? what happens when zones are destroyed? are these services monitoring zone state changes? - what happens to CPG associations during a zlogin (and other zone_enter() consumers). ------------------------------------------------------------------------------- --Boundary_(ID_UMvGjFOiSJU1TwEoD+6ghg)-- From casper@holland.sun.com Wed May 6 00:41:15 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 n467fEMW014443 for ; Wed, 6 May 2009 00:41:14 -0700 (PDT) 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 n467f2Zf029940; Wed, 6 May 2009 15:41:11 +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 <0KJ700003PCK5F00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 May 2009 00:41:08 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ700LINPCJO250@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 May 2009 00:41:07 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n467f4id033480; Wed, 06 May 2009 08:41:04 +0100 (BST) Date: Wed, 06 May 2009 09:41:04 +0200 From: Casper.Dik@sun.com Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <57FC2053-3CEF-47AF-AA18-B87E3DBAF093@usa.net> Sender: casper@holland.sun.com To: Boyd Adamson Cc: "Garrett D'Amore" , Nicolas Williams , psarc-ext@sun.com Message-id: <200905060741.n467f4id033480@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49F8794C.5060805@sun.com> <20090430195832.GM1500@Sun.COM> <200905041138.n44BcQ5q050240@dm-holland-02.uk.sun.com> <20090504153147.GZ1500@Sun.COM> <200905041537.n44Fbk3o063175@dm-holland-02.uk.sun.com> <20090504154734.GA1500@Sun.COM> <200905041727.n44HR0e7036430@dm-holland-02.uk.sun.com> <20090504182354.GN1500@Sun.COM> <20090505154056.GV1500@Sun.COM> <4A00612F.3040007@sun.com> <57FC2053-3CEF-47AF-AA18-B87E3DBAF093@usa.net> Status: RO Content-Length: 368 >I can see the problem. I can't immediately think of a solution, but an >option that selects only processes that belong to a particular CPG (a >la -p, -z, -t) may be useful and not too hard What we clearly miss in "ps" is more control on the output; it would be nice to use something like: ps -o zone:12,user:9, etc. This gives you more control. Casper From casper@holland.sun.com Wed May 6 00:43:08 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 n467h6vR014484 for ; Wed, 6 May 2009 00:43:06 -0700 (PDT) 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 n467gpxN001025 for <@sunmail2sca.sfbay.sun.com:psarc-ext@Sun.COM>; Wed, 6 May 2009 15:43:05 +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 <0KJ700N03PFT1R00@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 06 May 2009 01:43:05 -0600 (MDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ700ELHPFS9J40@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 06 May 2009 01:43:04 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n467h3l9034018; Wed, 06 May 2009 08:43:03 +0100 (BST) Date: Wed, 06 May 2009 09:43:02 +0200 From: Casper.Dik@sun.com Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) Sender: casper@holland.sun.com To: Nicolas Williams , psarc-ext@sun.com Message-id: <200905060743.n467h3l9034018@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 160 Another question about this project: how is this project going to be used. When this project is completed, which consumer will be putback with this? Casper From Nicolas.Williams@sun.com Wed May 6 07:31:33 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 n46EVW7g020563 for ; Wed, 6 May 2009 07:31:33 -0700 (PDT) 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 n46EVTAn005724; Wed, 6 May 2009 15:31:30 +0100 (BST) 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 <0KJ8006038CH0M00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 May 2009 07:31:29 -0700 (PDT) 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 <0KJ8004E98CH4X20@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 May 2009 07:31:29 -0700 (PDT) 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 n46ETHtG026060; Wed, 06 May 2009 09:29:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n46ETHqY026059; Wed, 06 May 2009 09:29:17 -0500 (CDT) Date: Wed, 06 May 2009 09:29:17 -0500 From: Nicolas Williams Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <200905060741.n467f4id033480@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: Boyd Adamson , "Garrett D'Amore" , psarc-ext@sun.com Message-id: <20090506142917.GE1500@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: <20090504153147.GZ1500@Sun.COM> <200905041537.n44Fbk3o063175@dm-holland-02.uk.sun.com> <20090504154734.GA1500@Sun.COM> <200905041727.n44HR0e7036430@dm-holland-02.uk.sun.com> <20090504182354.GN1500@Sun.COM> <20090505154056.GV1500@Sun.COM> <4A00612F.3040007@sun.com> <57FC2053-3CEF-47AF-AA18-B87E3DBAF093@usa.net> <200905060741.n467f4id033480@dm-holland-02.uk.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: 732 On Wed, May 06, 2009 at 09:41:04AM +0200, Casper.Dik@Sun.COM wrote: > > > >I can see the problem. I can't immediately think of a solution, but an > >option that selects only processes that belong to a particular CPG (a > >la -p, -z, -t) may be useful and not too hard > > > What we clearly miss in "ps" is more control on the output; > it would be nice to use something like: > > ps -o zone:12,user:9, > > etc. > > This gives you more control. Yes, and we could do something like this too: ps -o cpgid-krb5 ps -o cpgudata-krb5 ... Where any column named cpgpid- has CPG IDs for CPGs of that type as the value, and cpgid- has CPG user data for CPGs of that type as the value. Nico -- From Nicolas.Williams@sun.com Wed May 6 07:56:07 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 n46Eu76b021237 for ; Wed, 6 May 2009 07:56:07 -0700 (PDT) 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 n46Eu5fM014844; Wed, 6 May 2009 07:56:06 -0700 (PDT) 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 <0KJ800J199HI4G00@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 07:56:06 -0700 (PDT) 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 <0KJ800FX39HGO250@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 07:56:04 -0700 (PDT) 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 n46ErsUP026081; Wed, 06 May 2009 09:53:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n46ErsA4026080; Wed, 06 May 2009 09:53:54 -0500 (CDT) Date: Wed, 06 May 2009 09:53:54 -0500 From: Nicolas Williams Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <20090506052949.GA1384@eng.sun.com> To: Stephen Hahn Cc: "Garrett D'Amore" , PSARC-ext Message-id: <20090506145354.GF1500@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: <49F8794C.5060805@sun.com> <20090506052949.GA1384@eng.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: 6286 On Tue, May 05, 2009 at 10:29:52PM -0700, Stephen Hahn wrote: > Interesting proposal. Of the bikeshed options, I like the ones with > "credential" in them over those mentioning "session" or "process > group" (since there are no process collectives that allow pre-existing > processes to join them). > > Some questions: > > 1. What are the default registered CPG types on a newly booted > system? (Are there CPG types created by the kernel prior to the > creation of init(1M)?) None. They are registered by SMF services using the cpg_type_reg(2) system call. > 1'. If the kernel does create such types, how do they participate in > the "resource release at empty" operation? See above. > 2. Why 64-bit IDs, and not reuse of id_t and idtype_t? (Unusual for > a process collective.) To avoid ID wraparound, reuse. A CPG ID will be unique since boot. Garret plans to use the CPG ID to effect revocation of audio devices, for example. I think that would work like so: when an audio CPG is associated with an audio device the CPG's ID will will be recorded in the open audio node, then later, when the user logs out, all the CPG IDs in the audio node will be removed so that any remaining open file references will have CPG IDs that the device won't recognize. (We really need a BSD-like revoke(2), but this revocation on the cheap is a good deal.) > 3. What is the complete list of system calls that cause a CPG to > change its settings? For instance, should setuid(2) or > setppriv(2) calls also have CPG_F_* flags? No system calls other than the cpg_change(2) and cpg_change_to(2) system calls change a process' CPG membership. The CPG_F_AT_* cpg_change(2) flags are for use by login applications (including su(1)) and PAM modules. The CPG_S_CHG_AT_* semantics flags correspond to the CPG_F_AT_*. We could certainly have a CPG_S_CHG_AT_ semantic flag that indicates that the CPG should change on any system call that materially changes the process' cred_t. That could be a useful way of obtaining a cred_t ID. But I don't see the need for that yet, and the beauty of the semantics flags is that we can add this later. > 4. There's no new privilege needed for CPG type registration or > removal? What privilege is required? All zone privs. (I should have included a pointer to the prototype webrev in the ARC materials... The code for this is there. But also, I should have added text in the manpages for this too.) > 5. Do you expect the behaviour of a cpg_type_unreg() call to be > blocking--destroying all CPGs of that type--or merely allow those > CPGs to linger until all processes have exited. What happens to > CPGs with door calls in the _unreg() case? Good question. I would want the cleanup to be non-blocking, but since it involves potential door upcalls it can't be non-blocking, so it has to be blocking.. On the other hand, I'm not sure there's any point to unregistering CPG types. So I think I'd rather remove the cpg_type_unreg() call. (I had it in there for completeness, but now see it's not needed.) > 6. It would be helpful to see the Boomer example explained a bit, if > any preliminary sketch is available. (My feeling is that there's > a lot of public mechanism for one consumer.) Think of /dev/tty, but for audio. You login on console, or a VT, or some other "seat" (think SunRay), and your seat has an audio device associated with it. Your apps should be able to find it. Environment variables leave something to be desired... With a CPG finding the device is easy: either a user-land app could read the device name from the CPG user data (that would be by convention for the audio CPG type) or it would open a /dev/tty-like device that finds the real device from module data associated with the CPG. Plus revocation is easy: open file references to an audio device will work provided that the CPG ID for the audio CPG of the cred_t in the open file reference matches a CPG ID recorded in the device node. > 7. Usually the zone/project/task/process resource controls need to be > transferred in the attributes of the work unit of whatever > subsystem is taking the request out of process context but, if > you've worked out more about subsuming those attributes, I'd be > interested in seeing the details. I'm not sure I follow. If this is about whether CPG usage requires resource controls then the answer is clear: the limit on processes is a limit on how many CPGs a user can have (technically a process could have as many cred_ts as threads for brief periods, also, a user could consume more CPGs via open file references, so the actual limit on CPGs is going to be the user's [project's/task's] open file descriptor limit). If your comment is about the note that task ID could move from proc_t into a CPG, since every process (and thread) has a cred_t then it should be possible to have access to a task ID anywhere where it's needed now, even if task ID moves into a CPG. > 8. Could the project team comment when they expect a new feature > should introduce a CPG type, rather than a process privilege? It > might also be useful to understand how CPGs might be used to > implement a concept like a security label, as in classic Trusted > Solaris? I suppose I'm looking for early advice about how to > design using this feature. (For instance, if the answer to 1/1' > is "no", then does that imply kernel features must introduce > privileges?) CPGs could, indeed, be used to hold security labels, audit context, and other things. Anything that's in cred_t now could be wrapped in a CPG. But we could take things too far. I would not want to put uid/euid/ suid, and GIDs into a CPG -- that makes little sense. A feature should introduce a CPG type instead of a privilege only if access control by membership in a CPG is more desirable than by privilege. Even then privilege is needed in order to establish that some CPG has access to some resource -- a task that should be done by a PAM cred module, which should run in a PAM application, which should run with all zone privileges. I hope that answers your questions. Nico -- From Nicolas.Williams@sun.com Wed May 6 08:04:51 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 n46F4pRp001023 for ; Wed, 6 May 2009 08:04:51 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n46F4k9T006567; Wed, 6 May 2009 08:04:50 -0700 (PDT) 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 <0KJ800J3H9W1J200@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 08:04:49 -0700 (PDT) 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 <0KJ800FQR9W0O460@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 08:04:49 -0700 (PDT) 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 n46F2dXQ026089; Wed, 06 May 2009 10:02:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n46F2dCB026088; Wed, 06 May 2009 10:02:39 -0500 (CDT) Date: Wed, 06 May 2009 10:02:39 -0500 From: Nicolas Williams Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <200905060743.n467h3l9034018@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: psarc-ext@sun.com Message-id: <20090506150239.GG1500@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: <200905060743.n467h3l9034018@dm-holland-02.uk.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: 1768 On Wed, May 06, 2009 at 09:43:02AM +0200, Casper.Dik@Sun.COM wrote: > Another question about this project: how is this project going to be used. > > When this project is completed, which consumer will be putback with this? We have two consumers lined up right now: - Boomer - Solaris Kerberos See my and Garret's reply to Stephen Hahn about how Boomer would use CPGs (basically: in a way not too dissimilar to the controlling tty and session ID concept). Solaris Kerberos would use it the way AFS classically uses PAGs: to associate a credentials cache with a group of processes, where the group is determined by something other than their euid. Today Solaris Kerberos associates credentials caches with processes by euid: the NFS client triggers an upcall to gssd which then does a seteuid() to the euid of the process that triggered the upcall, and then gssd calls gss_init_sec_context(3GSS) and friends. This has a number of sad side-effects, such as: a) we're stuck doing something like /tmp/krb5cc_, with attendant problems, b) all login sessions by a user must share a ccache, which means we need some sort of reference count so that the user's krb5 creds are destroyed only when the last session ends, c) AFS users often like to run different login sessions for the same user but with different krb5 creds. (a) and (b) can be solved without new kernel features, but in all these years it's not been done, and it would fork Solaris Kerberos more from MIT krb5 at a time when the Solaris Kerberos team would like to reduce the differences between Solaris and MIT krb5. (c) is something that the OpenAFS folks keep asking for -- friends of mine in the OpenAFS world have been asking me for a PAG-like feature in Solaris since about 2002. Nico -- From Nicolas.Williams@sun.com Wed May 6 08:19:04 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 n46FJ4Ir018311 for ; Wed, 6 May 2009 08:19:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n46FJ0pY023249; Wed, 6 May 2009 09:19:03 -0600 (MDT) 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 <0KJ800M0RAJQED00@brm-avmta-1.central.sun.com>; Wed, 06 May 2009 09:19:02 -0600 (MDT) 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 <0KJ800JX9AJP1U70@brm-avmta-1.central.sun.com>; Wed, 06 May 2009 09:19:02 -0600 (MDT) 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 n46FGq6S026097; Wed, 06 May 2009 10:16:52 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n46FGqA7026096; Wed, 06 May 2009 10:16:52 -0500 (CDT) Date: Wed, 06 May 2009 10:16:52 -0500 From: Nicolas Williams Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <20090506070244.GB329918@eng.sun.com> To: Edward Pilatowicz Cc: "Garrett D'Amore" , PSARC-ext Message-id: <20090506151652.GH1500@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: <49F8794C.5060805@sun.com> <20090430195832.GM1500@Sun.COM> <20090506070244.GB329918@eng.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: 3949 On Wed, May 06, 2009 at 12:02:45AM -0700, Edward Pilatowicz wrote: > so i started reviewing these materials from a zones integration > perspective, but while reading them i realized that i had a lot of > general questions as well wrt how this functionality would actually > work. i've attached my questions, broken into two sections. first > is the general questions (to help me understand this stuff better) > and second is the zones related questions. Thanks. Answers below. > - you repeatedly state that CPGs are associated with login sessions. > please define a login session in the CPG context and provide examples. A login session is the set of processes running as the PAM_USER that result from a successful attempt to login, whether on console, via ssh, etc... Two concurrent logins by the same user on the same host would be two different login sessions -- they'd have different CPG IDs for the various CPG types. > you also mention that CPGs will help with obtaining credentials for cron > jobs, which specifically don't have a login session (as i understand > login sessions), so please explain how this works. Yes, I did not flesh that out. That was an indirect reference to a problem in Solaris Kerberos where all processes running as a user must share the same Kerberos credentials because the only way that the Kerberos credentials can be found by the secure NFS client right now is by referencing the euid of the process that's causing an NFS RPC. Solaris Kerberos right now does nothing to reference count the Kerberos credentials cache of a user, which causes a variety of problems. The cron angle is somewhat indirect, and really will require a way to make Kerberos credentials available to cron for later use, so I should not have mentioned cron except as a future beneficiary of this project. > - you mention that CPGs are bound to credentials (there seems to be a > 1:1 mapping), but in my gdm login session, different xterms have > different cred_t pointers. so will different xterms have different > CPGs? (once again, perhaps this confusion results from my lack of > understanding of how "login sessions" are defined wrt CPGs.) A process' cred_t changes when a setuid/setgid program is executed, even if in the end (that is, after the app drops privs) that process' cred_t ends up looking just like its parent. CPG membership is inheritted across all system calls that change a cred_t OTHER THAN cpg_change(2) and cpg_change_to(2). That is, CPG membership changes are always explicit, though because most often only login apps/PAM modules will call cpg_change(2) users will not have to take explicit steps w.r.t. CPG membership. (AFS users will often take explicit steps to change CPG membership, as they do today with the pagsh(1) command -- see the manpage reference in the AFS readme in the case materials. But that's entirely optional.) > - group membership is represented in cred_t. does this impact cred_t > comparisons? (ala crcmp()). Yes, it does. See the cpg_change manpage in the case materials, specifically this: CPG_S_DISTINGUISH_CRED Processes with process credentials that differ only with respect to membership in CPGs whose semantics include this flag will be treated as having distinct process credentials by the kernel private function crcmp(). > - why must CPGs IDs be unique (since boot)? Because it will be useful for projects that want a cheap way to do access control and revocation. See my reply to Stephen Hahn on this point. > - why isn't ps(1) being modified to display the CPGs ID? Because I hadn't thought of it, or how to do it. However last night I thought of a way: add columns named cpgid- and cpgudata- whose values will be CPG IDs and CPG user data for CPGs of the given type. More later. I've a doctor's appointment (I think I injured my shoulder at the gym two days ago). Nico -- From gdamore@sun.com Wed May 6 08:35:56 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 n46FZtnZ018922 for ; Wed, 6 May 2009 08:35:56 -0700 (PDT) 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 n46FZgIi013864 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 6 May 2009 23:35:54 +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 <0KJ80000JBBSVM00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 06 May 2009 09:35:52 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ800JI8BBS1YB0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 06 May 2009 09:35:52 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n46FZqm6020622 for ; Wed, 06 May 2009 08:35:52 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ800M00BA6DR00@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 06 May 2009 08:35:52 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ8004JIBBROU60@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 06 May 2009 08:35:51 -0700 (PDT) Date: Wed, 06 May 2009 08:35:50 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <200905060743.n467h3l9034018@dm-holland-02.uk.sun.com> Sender: Garrett.Damore@sun.com To: Casper.Dik@sun.com Cc: Nicolas Williams , PSARC-ext@sun.com Message-id: <4A01AE56.7010509@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: <200905060743.n467h3l9034018@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 281 Casper.Dik@Sun.COM wrote: > Another question about this project: how is this project going to be used. > > When this project is completed, which consumer will be putback with this? > > Casper > > Probably the Boomer/Sun Ray audio code will be the first consumer. - Garrett From Nicolas.Williams@sun.com Wed May 6 10:02:39 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 n46H2bD9024362 for ; Wed, 6 May 2009 10:02:37 -0700 (PDT) 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 n46H2XAI015824; Wed, 6 May 2009 18:02:34 +0100 (BST) 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 <0KJ800209FC8OZ00@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 10:02:32 -0700 (PDT) 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 <0KJ800145FC8EP10@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 10:02:32 -0700 (PDT) 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 n46H0Org026119; Wed, 06 May 2009 12:00:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n46H0OkZ026118; Wed, 06 May 2009 12:00:24 -0500 (CDT) Date: Wed, 06 May 2009 12:00:24 -0500 From: Nicolas Williams Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <20090506070244.GB329918@eng.sun.com> To: Edward Pilatowicz Cc: "Garrett D'Amore" , PSARC-ext Message-id: <20090506170023.GI1500@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: <49F8794C.5060805@sun.com> <20090430195832.GM1500@Sun.COM> <20090506070244.GB329918@eng.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: 8715 Picking up where I left off... On Wed, May 06, 2009 at 12:02:45AM -0700, Edward Pilatowicz wrote: > - is the CPG door upcall mechanism used for anything other than a > notification for when a CPG group becomes empty? (i'm worried that > perhaps we're adopting the linux behaviour of having the kernel spawn > processes to prompt the user for information.) Kernel consumers would be allowed to use that door for other purposes, yes, though I've not yet established the protocol for doing that. That does compare to the Linux keyring "upcall" feature, though unlike the Linux keyring upcall this scheme does not involve the kernel spawning processes. More importantly, I don't think this upcall facility should be used for prompting users so much as for accessing material not stored in the kernel, much like the NFS/RPCSEC_GSS code does in upcalling to gssd to access users' Kerberos V and DH credentials. I.e., we already have a precedent for this feature and I don't see what should be controversial about it, though I think the Linux scheme in particular is controversial. > - given that CPGs are associated with credentials, how could they > replace process project(4)s and tasks, which can contain process > with different credentials? CPGs wouldn't replace project or task IDs, but they could be moved into a CPG type. The reason for this is that a) every process has a cred_t, so we can find that process' project/task through cred_t if need be, b) CPG membership is inheritted across fork(), exec(), setuid(), etcetera, unless explicit action is taken to change CPG membership. See my other answers to others on this same point. > - you mention encoding ssh agent information in CPGs. afaik, the > current problem with ssh agent environment variables is that if > someone connects to a machine via ssh, starts the ssh agent, then logs > into the machine again via ssh, the second login session won't know > about the agent started by the first session. how can CPGs solve this > problem? That's a problem with ssh-agent that CPGs don't solve since joining an existing CPG is no simpler than finding the SSH_AUTH_SOCK env var value of another login session's processes and then setting it. > - you mention that on linux, a process may manipulate it's parents PAGs. > will this be possible for solaris? (i'm hoping the answer is no.) Yes, it is possible (and that's a feature of AFS PAGs, not so much Linux keyrings). > if it's yes, could you please site me some examples of subsystems > where a subprocess is allowed to modify it's parents properties? Such things can be done through /proc today. There's no subsystem where I think that is necessary, but that doesn't mean that it shouldn't be possible, if anything else, from a debugging perspective. In the AFS usage the reason for this facility is so that pagsh(1) can change the PAG membership of an interactive shell from which it's spawned _as though pagsh were a shell builtin_. > (i can think of examples where one process can modify another via > /proc or some -p type option, but these are all subject to priv > checks and not just blindly permitted because there is some kind of > causal relationship between the two processes.) Privileges apply here as well: you need PRIV_PROC_SESSION to change the CPG membership of processes running as you, and you need PRIV_PROC_OWNER to change the CPG membership of processes not running as you (or perhaps this latter should require all zone privs). > - cpg_chown() and cpg_chown_byid() > > please define a CPG owner. It's a UID (uid_t), specifically it should be the UID of the user whose login session the CPG is associated with. > (do CPGs have an owner that is separate > from the cred_t associated with the CPG?) Yes because CPG membership is inheritted across setuid() and friends. > when would you ever want to change the ownership of a CPG? At login and su time it should happen automatically, otherwise it should be done explcitly is the user has a need for it. In the AFS world users typically run different process groups with different Kerberos credentials (e.g., one runs with access to a ccache with a TGT for joeuser@JOESREALM and another with access to a TGT for joeuser/admin@JOESREALM, or joe@FRIENDSREALM). > what happens to all the processes bound to that CPG when it's > ownership changes? Nothing. CPG ownership relates to who can get/set CPG user data. > - it seems like there are a lot of CPG data modifier flags. are > CPG_S_SESSION_PRIVATE_DATA and CPG_S_SENSITIVE_DATA really useful? > > they require proc_session and proc_info respectively, and both > these privs are included in the basic set, so who are you actually > protecting this "private/sensitive" data from? Think sandboxing. I'm not sure that this approach is necessarily useful given security labeling. But I threw it in for completeness and as a way to explore extensibility through these semantics flags. We should remove the ones that we can't find uses for. > - a 64-byte user data field for a CPG seems small. how did you decide > on this size? is there any reason the size isn't specified when the > CPG type is created? It's arbitrary. It could be set to more, as long as it's fixed. It has to be fixed because of ucred_size(3C) (ucreds are an opaque octet string that can be passed around, and the system sets the max ucred size at boot time); alternatively the CPG user data could be left out of the ucred object. > - why bother with _CONFIG_NCPGROUPS? (it seems like it would be more > usefull to have a sysconf variable for the size of the user data if > you plan to keep it as a fixed size. using sysconf for this instead of > a define would allow for easier increases of the value in the future.) My intention is to have this be a sysconf, indeed. See above for why _CONFIG_NCPGROUPS needs to be fixed at boot time. > ------------------------------------------------------------------------------- > zones questions: > > - this worries me: > - New CPG types can be registered early at boot time in the global > zone > > why isn't the CPG type namespace unique across zones and why can't > zones create their own CPG types? I couldn't find a good reason for CPG type names to not be globally unique, but I'm willing to change this, of course. > why can CPGs only be created early in boot? please define early. Technically they can be created at any time, but you'd want them to be all registered before login services start, which is why I think they should be registered early in boot. > the cpg(1) command seems to be able to create and destroy cpg types. > will this command fail if it's run after the system is booted? No. > if CPG types can be created after boot, are there any resource limits > on CPG type creation? are there any privs to control CPG type > creation? All privs are needed to register new CPG types. The only applicable resource control is _CONFIG_NCPGROUPS (see above). > - if CPGs are used by things like kerberos, and kerberos is not enabled > in the global zone, but it is enabled for a non-global, how will the > kerberos CPG type be registered? (this also applies to other services > that may use CPGs in the future, like ssh, etc.) The gz admin has to do it (by enabling the relevant service(s)) knowing that the ngzs will need it. > - this also worries me: > CPG types will be registered in the global zone by an SMF service > per-CPG type. These services will also be able to register a door (in > the global zone and in non-global zones) that will receive upcalls > indicating CPG emptiness events. > > so global zone services are registering doors within zones? doors are > bound to paths. so how do these services deal with zones that are not > mounted, attached, installed? what happens when zones are destroyed? > are these services monitoring zone state changes? Oh that's terrible wording on my part! I meant that these services could run in the gz and ngzs, but that CPG type registration would only happen in the gz. > - what happens to CPG associations during a zlogin (and other > zone_enter() consumers). zlogin should clear them, but it's OK if that is not allowed by the CPG type's semantics. Think of audit context, which IIRC isn't changed across zone_enter() -- if a CPG type does not allow changing CPG membership once a CPG is joined, then it shouldn't be cleared across zone_enter(). But if I'm wrong about audit context inherittance across zone_enter() then I would agree all CPG memberships should be cleared across zone_enter(). Nico -- From Nicolas.Williams@sun.com Wed May 6 10:07:24 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 n46H7N0M024912 for ; Wed, 6 May 2009 10:07:23 -0700 (PDT) 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 n46H7KXe019208; Wed, 6 May 2009 18:07:21 +0100 (BST) 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 <0KJ800213FK8W400@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 10:07:20 -0700 (PDT) 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 <0KJ8001JVFK7EP10@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 10:07:20 -0700 (PDT) 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 n46H5Csl026135; Wed, 06 May 2009 12:05:12 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n46H5Cbr026134; Wed, 06 May 2009 12:05:12 -0500 (CDT) Date: Wed, 06 May 2009 12:05:12 -0500 From: Nicolas Williams Subject: Re: PSARC 2009/271 Credential Process Groups (CPGS) In-reply-to: <20090505232329.GA1194@sun.com> To: Will Fiveash Cc: PSARC-ext@sun.com Message-id: <20090506170511.GK1500@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: <20090505232329.GA1194@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: 837 On Tue, May 05, 2009 at 06:23:29PM -0500, Will Fiveash wrote: > In > http://sac.sfbay.sun.com/Archives/CaseLog/arc/PSARC/2009/271/inception.materials/Overview-terse.txt > there is: > > Architecture: > > CPG membership is driven primarily by PAM modules and applications: > > ... > > - svc:/system/cpg/krb5:default registers the "krb5" CPG type and runs a > daemon to kdestroy Kerberos V credentials when the last reference to > a CPG vanishes. > > How does this interact with svc:/network/security/ktkt_warn? Seems to > me that there should be one service tending to the needs of the krb5 > related ccache. Perhaps the function of ktkt_warn can be folded into > svc:/system/cpg/krb5? I think so too, but I haven't thought enough about this. Either ktkt_warn should move into svc:/system/cpg/krb5 or vice-versa. Nico --