From sacadmin Wed Apr 27 14:33:08 2005 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j3RLX7Sp024258; Wed, 27 Apr 2005 14:33:07 -0700 (PDT) Received: (from darrenm@localhost) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9/Submit) id j3RLX789024254; Wed, 27 Apr 2005 14:33:07 -0700 (PDT) Date: Wed, 27 Apr 2005 14:33:07 -0700 (PDT) From: Darren J Moffat Message-Id: <200504272133.j3RLX789024254@sac.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Subject: Per user Authentication Policy [PSARC/2005/275 Timeout: 05/04/2005] Status: RO Content-Length: 4398 Lines: 131 Subject: PSARC FastTrack [05/04/2005]: Per user Authentication Policy I'm sponsoring this case for the PAM per user project team. The team is: Nicolas Williams, Darren Moffat, Gary Winiger. This case depends on PSARC 2005/217 only to simplify the implementation of the delivered configurations, it is not architecturally dependent on PSARC/2005/217 and thus may deliver before it if it does not use the include derective in the implementation of the default configurations. Template Version: @(#)sac_nextcase 1.55 08/11/04 SMI Copyright 2005 Sun Microsystems, Inc. 1. Introduction 1.1. Project/Component Working Name: Per user Authentication Policy 1.2. Name of Document Author/Supplier: Author: Nicolas Williams 1.3 Date of This Document: 27 April, 2005 4. Technical Description ABSTRACT -------- This case adds support for per-user PAM configuration, a highly desirable feature. No changes are needed to PAM applications or modules, nor does libpam become unnecessarily Unix-specific. The case introduces a PAM module, pam_user_policy(5), which loads and evaluates, by calling a new PAM function, pam_eval(3PAM), a PAM configuration named in a user_attr(4) and/or prof_attr(4) ('pam_policy'). BACKGROUND ---------- PAM supports a single configuration per-service. This restriction was reasonable initially, but over time it has caused problems. For example, it has caused the names of locally defined users, specifically 'root', to be hard-coded in modules which are typically not appropriate for such users (e.g., pam_krb5). And customers managing migrations, for example, from Unix authentication to Kerberos V authentication often need PAM to distinguish between two kinds of users: migrated and not. HP-UX and MacOS X both have some support for per-user PAM configuration. HP-UX includes a module which searches for and evaluates a PAM configuration stored in a file named after the user. MacOS X includes a module which implements authentication strategies configured in an LDAP directory on a per-user basis. This case proposes a Solaris PAM module which includes a PAM configuration named in a user_attr(4) user attribute. We need a solution that has the following characteristics: - easy administration of policies assigned to users - no changes are required to 3rd party PAM applications - no changes are required to 3rd party PAM modules - libpam does not treat PAM_USER values as Unix usernames (Solaris PAM modules, of course, do) PROPOSAL -------- We propose: - A new PAM function, which can be called only by modules, pam_eval(3PAM). This function loads and evaluates a PAM configuration stored in file named by the caller. - A new PAM module, pam_user_policy(5) which looks up the PAM_USER's 'pam_policy' user_attr(4), or in the user's profiles (prof_attr(4)) and pam_eval()'s the named configuration, if any, or returns PAM_IGNORE. The pam_user_policy(5) auth module will prompt for a PAM_USER, if one is not set. The intention is that it be possible to stack pam_user_policy above all other modules in all stacks with zero effect for users who have no pam_policy user_attr or prof_attr. - A set of PAM configuration files, in /usr/lib/security/, intended for inclusion via pam_user_policy(5): - unix.conf - krb5.conf - krb5-fallback-unix.conf - ldap.conf - any.conf - No change to /etc/pam.conf is proposed. However, it's expected that a future case will likely change the default pam.conf so that pam_user_policy is stacked as binding at the top of most every service stack. DOCUMENTATION ------------- - New man pages will be added for pam_eval(3PAM) and pam_user_policy(5). See case repository. - The user_attr(4) and prof_attr(4) man pages will be modified to mention 'pam_policy' and reference pam_user_policy(5). See case repository. INTERFACE STABILITY AND RELEASE BINDINGS ---------------------------------------- Interface Stability Release Binding pam_eval(3PAM) Stable Minor/patch pam_user_policy(5) Stable Minor/patch config file names Stable Minor/patch config file semantics Stable Minor/patch config file contents Unstable Minor/patch 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack From sacadmin Tue May 3 16:07:56 2005 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.11.21]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j43N7us0016696; Tue, 3 May 2005 16:07:56 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j43N7tkH028323; Tue, 3 May 2005 16:07:55 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id j43N7WG0004917; Tue, 3 May 2005 16:07:32 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id j43N7WEI004916; Tue, 3 May 2005 16:07:32 -0700 (PDT) Date: Tue, 3 May 2005 16:07:32 -0700 (PDT) From: Gary Winiger Message-Id: <200505032307.j43N7WEI004916@marduk.eng.sun.com> To: PSARC@sac.sfbay.sun.com, darrenm@sac.sfbay.sun.com Cc: gww@eng.sun.com, nicolas.williams@sun.com Subject: Re: Per user Authentication Policy [PSARC/2005/275 Timeout: 05/04/2005] Status: RO Content-Length: 696 Lines: 15 > Subject: PSARC FastTrack [05/04/2005]: Per user Authentication Policy > I'm sponsoring this case for the PAM per user project team. The > team is: Nicolas Williams, Darren Moffat, Gary Winiger. Even though I am indeed part of the project team, I need more time. I believe this case is premature and the project is incomplete because of it. I'm working on the details to support these claims. With the loss of connectivity this week, I'm probably not going to have enough of the details. I'm not opposed to the thrust of the case, just some details and dependences. I've discussed a number of points offline that I'll try to get online before tomorrow, but can't promise. Gary.. From sacadmin Tue May 3 17:34:54 2005 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.11.21]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j440Yss0020594; Tue, 3 May 2005 17:34:54 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j440YqkH008276; Tue, 3 May 2005 17:34:52 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id j440YUKQ005230; Tue, 3 May 2005 17:34:30 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id j440YS6V005229; Tue, 3 May 2005 17:34:28 -0700 (PDT) Date: Tue, 3 May 2005 17:34:28 -0700 (PDT) From: Gary Winiger Message-Id: <200505040034.j440YS6V005229@marduk.eng.sun.com> To: PSARC@sac.sfbay.sun.com, darrenm@sac.sfbay.sun.com, gww@marduk.eng.sun.com Cc: gww@eng.sun.com, nicolas.williams@sun.com Subject: Re: Per user Authentication Policy [PSARC/2005/275 Timeout: 05/04/2005] Status: RO Content-Length: 6151 Lines: 149 > incomplete because of it. I'm working on the details to support > these claims. With the loss of connectivity this week, I'm probably > not going to have enough of the details. Jurassic is about to get unplugged by ITOPS, so I'm stopping here. Gary.. > This case depends on PSARC 2005/217 only to simplify the implementation > of the delivered configurations, it is not architecturally dependent > on PSARC/2005/217 and thus may deliver before it if it does not use > the include derective in the implementation of the default configurations. Clarification: Is this statement intended to say that > - unix.conf > - krb5.conf > - krb5-fallback-unix.conf > - ldap.conf > - any.conf though in the materials directory these files all contain "include" control flags that an alternate implementation could be provided? > The case introduces a PAM module, pam_user_policy(5), which loads and > evaluates, by calling a new PAM function, pam_eval(3PAM), a PAM > configuration named in a user_attr(4) and/or prof_attr(4) > ('pam_policy'). I believe it is wrong to add more to user_attr(4) and increase the likelyhood of the train wreck that is looming. 6255542 which the project team is well aware of details the the issue. In short, for this discussion: o user_attr has a 1024 byte limit. user_attr was not architected in RBAC to scale. user_attr is difficult to manage as it is per user and cannot have a modification in one place apply to many users. user_attr already has enough key=value pairs that it can easily overflow the 1024 byte limit. o there is no administrative interface for managing "pam_policy." Thus, there is no way to assign this value to a user and the case is incomplete. Therefore, I believe this case must be dependent on a case yet to be defined to add the existing user_attr and "pam_policy" keys to prof_attr which was architected to scale and manage multiple users with a single update. I believe that case must provide an administrative interface for managing the key=value pairs in the user_attr and prof_attr databases. I believe it is reasonable to have a policy.conf(4) default for "pam_policy". Most (all) user_attr/prof_attr keys have per machine defaults. I believe this case should include the per machine default. > BACKGROUND > ---------- > > PAM supports a single configuration per-service. This restriction was > reasonable initially, but over time it has caused problems. For > example, it has caused the names of locally defined users, specifically > 'root', to be hard-coded in modules which are typically not appropriate > for such users (e.g., pam_krb5). And customers managing migrations, for > example, from Unix authentication to Kerberos V authentication often > need PAM to distinguish between two kinds of users: migrated and not. How does this case automatically distinguish between migration? How does this case relate to 2004/264 pam_krb5 unknown Kerberos principles 2004/216 pam_krb5_migrate? Does it obsolete or replace any of this work with another mechanism for Kerberos? > We need a solution that has the following characteristics: > > - easy administration of policies assigned to users Thus my belief this case must depend on the case that administers pam_policy and doesn't add to the likelyhood of a train wreck. Part of the initial project discussion was to work to obsolete the server_policy flag that was introduced in 2002/270 pam_ldap account control on pam_unix_auth, pam_unix_account, pam_passwd_auth, and pam_authtok_store. I fail to see how this case addresses those issues (possibly beyond supplying a .conf file that is preconfigured with the right binding and server_policy stuff to eliminate the need to actually read instructions and accurately type). Is working to obsolete the server_policy flag something that this case cannot help with? > PROPOSAL > -------- > > We propose: > > - A new PAM function, which can be called only by modules, > pam_eval(3PAM). NIT: The description could be clearer. IMO it should state in the first paragraph that it evaluates the current service and module type. RETURN VALUES. Does it really return PAM_SYSTEM_ERR, or does it return the error that would be returned by the existing libpam routines if they have problems with pam.conf. Not all of these problems are reported as PAM_SYSTEM_ERR. If it is making its own decisions, what syslog interaction does it have? > - A new PAM module, pam_user_policy(5) which looks up the PAM_USER's > 'pam_policy' user_attr(4), or in the user's profiles (prof_attr(4)) > and pam_eval()'s the named configuration, if any, or returns > PAM_IGNORE. What flags does this take? RETURN VALUES: The interaction with pam_eval returning PAM_IGNORE seems wrong unless this is the absolute only service module in the pam stack that will be used if there is a ``pam_policy'' value found. Also building in knowledge of the default errors into a service module seems wrong. Libpam understands the defaults. perhaps there needs to be a way to have libpam do the right thing. In any case pam_user_policy seems under specfied. > DOCUMENTATION > ------------- > > - New man pages will be added for pam_eval(3PAM) and > pam_user_policy(5). See case repository. > > - The user_attr(4) and prof_attr(4) man pages will be modified to > mention 'pam_policy' and reference pam_user_policy(5). See case > repository. > > > INTERFACE STABILITY AND RELEASE BINDINGS > ---------------------------------------- > > Interface Stability Release Binding > > pam_eval(3PAM) Stable Minor/patch > pam_user_policy(5) Stable Minor/patch > config file names Stable Minor/patch > config file semantics Stable Minor/patch > config file contents Unstable Minor/patch If the names and file semantics are stable, there needs to be man pages describing them that I believe need to be part of this case. Without the man pages, I can't say I'm sure that the names are approachable. (P.S. that's not a call for UIRB invented names.) From sacadmin Wed May 4 09:05:27 2005 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j44G5Qs0022087; Wed, 4 May 2005 09:05:26 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j44G5OLQ004051; Wed, 4 May 2005 11:05:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j44G5NRM004050; Wed, 4 May 2005 11:05:23 -0500 (CDT) Date: Wed, 4 May 2005 11:05:23 -0500 From: Nicolas Williams To: Gary Winiger Cc: PSARC@sac.sfbay.sun.com, darrenm@sac.sfbay.sun.com, gww@eng.sun.com Subject: Re: Per user Authentication Policy [PSARC/2005/275 Timeout: 05/04/2005] Message-ID: <20050504160523.GA4008@binky.Central.Sun.COM> References: <200505040034.j440YS6V005229@marduk.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505040034.j440YS6V005229@marduk.eng.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 8764 Lines: 235 On Tue, May 03, 2005 at 05:34:28PM -0700, Gary Winiger wrote: > > This case depends on PSARC 2005/217 only to simplify the implementation > > of the delivered configurations, it is not architecturally dependent > > on PSARC/2005/217 and thus may deliver before it if it does not use > > the include derective in the implementation of the default configurations. > > Clarification: Is this statement intended to say that > > - unix.conf > > - krb5.conf > > - krb5-fallback-unix.conf > > - ldap.conf > > - any.conf > though in the materials directory these files all contain > "include" control flags that an alternate implementation could > be provided? Yes. From the case: config file names Stable Minor/patch config file semantics Stable Minor/patch config file contents Unstable Minor/patch > > The case introduces a PAM module, pam_user_policy(5), which loads and > > evaluates, by calling a new PAM function, pam_eval(3PAM), a PAM > > configuration named in a user_attr(4) and/or prof_attr(4) > > ('pam_policy'). > > I believe it is wrong to add more to user_attr(4) and increase > the likelyhood of the train wreck that is looming. 6255542 > which the project team is well aware of details the the issue. While I agree that we should add prof_attrs, I don't agree that we should not add corresponding user_attrs. It could well be (and I suspect will, in fact be) useful to be able to override profile attributes with user attributes. > In short, for this discussion: > o user_attr has a 1024 byte limit. NIS does. user_attr(4) itself does not. > user_attr was not architected in RBAC to scale. I'm not sure what you mean by this. > user_attr is difficult to manage as it is per user > and cannot have a modification in one place apply to > many users. The converse is that where there are many Picassos managing many profiles may be as difficult, or more so, as managing many user's attributes. > user_attr already has enough key=value pairs that > it can easily overflow the 1024 byte limit. See above. > o there is no administrative interface for managing > "pam_policy." Thus, there is no way to assign > this value to a user and the case is incomplete. There are administrative interfaces for managing user attributes. > Therefore, I believe this case must be dependent on a case > yet to be defined to add the existing user_attr and "pam_policy" > keys to prof_attr which was architected to scale and manage > multiple users with a single update. I believe that case > must provide an administrative interface for managing the > key=value pairs in the user_attr and prof_attr databases. This case adds both, a prof_attr and a user_attr for 'pam_policy'. That there is no administrative interface for managing profile attributes does not make this case worthless. For example, one could manage all local users' (e.g., root's) pam_policy user_attrs and then have the /etc/pam.conf entries following pam_user_policy provide a reasonable default for all non-local users. Or one could resort to managing user attrs. Or one could resort to managing profiles the way folks do it today, even lacking useful generic administrative interfaces. > I believe it is reasonable to have a policy.conf(4) default > for "pam_policy". Most (all) user_attr/prof_attr keys have > per machine defaults. I believe this case should include > the per machine default. The /etc/pam.conf contents below pam_user_policy provides a default. > > BACKGROUND > > ---------- > > > > PAM supports a single configuration per-service. This restriction was > > reasonable initially, but over time it has caused problems. For > > example, it has caused the names of locally defined users, specifically > > 'root', to be hard-coded in modules which are typically not appropriate > > for such users (e.g., pam_krb5). And customers managing migrations, for > > example, from Unix authentication to Kerberos V authentication often > > need PAM to distinguish between two kinds of users: migrated and not. > > How does this case automatically distinguish between migration? It doesn't. See below. > How does this case relate to > 2004/264 pam_krb5 unknown Kerberos principles PSARC 2004/264 can be used to distinguish, roughly, between migrated and non-migrated users. It has not been implemented. > 2004/216 pam_krb5_migrate? See above. pam_krb5_migrate was envisioned as a tool for temporary use only, so there should be no relation to this case. In practice, where customers continue to use it after full migrations, e.g., to "migrate" new users as new users are added, then customers will need to add some glue on the KDC to assign a profile to such users or set their pam_policy user_attr. > Does it obsolete or replace any of this work with another mechanism > for Kerberos? No. > > We need a solution that has the following characteristics: > > > > - easy administration of policies assigned to users > > Thus my belief this case must depend on the case that administers > pam_policy and doesn't add to the likelyhood of a train wreck. See above. > Part of the initial project discussion was to work to obsolete > the server_policy flag that was introduced in 2002/270 pam_ldap > account control on pam_unix_auth, pam_unix_account, pam_passwd_auth, > and pam_authtok_store. I fail to see how this case addresses > those issues (possibly beyond supplying a .conf file that is > preconfigured with the right binding and server_policy stuff > to eliminate the need to actually read instructions and > accurately type). Is working to obsolete the server_policy > flag something that this case cannot help with? This case will help to address the server_policy flag, but this case doesn't address it directly. > > PROPOSAL > > -------- > > > > We propose: > > > > - A new PAM function, which can be called only by modules, > > pam_eval(3PAM). > > NIT: The description could be clearer. IMO it should state > in the first paragraph that it evaluates the current service > and module type. Ok. > RETURN VALUES. Does it really return PAM_SYSTEM_ERR, or does > it return the error that would be returned by the existing > libpam routines if they have problems with pam.conf. PAM_SYSTEM_ERR is the error that makes sense. Do you have any alternative suggestions? > Not all > of these problems are reported as PAM_SYSTEM_ERR. If it is > making its own decisions, what syslog interaction does it have? I don't follow. What do you mean by "making its own decisions?" > > - A new PAM module, pam_user_policy(5) which looks up the PAM_USER's > > 'pam_policy' user_attr(4), or in the user's profiles (prof_attr(4)) > > and pam_eval()'s the named configuration, if any, or returns > > PAM_IGNORE. > > What flags does this take? None except for the ubiquitous "debug" -- I will add that to the man page. > RETURN VALUES: The interaction with pam_eval returning PAM_IGNORE > seems wrong unless this is the absolute only service module in > the pam stack that will be used if there is a ``pam_policy'' > value found. Also building in knowledge of the default errors > into a service module seems wrong. Libpam understands the defaults. > perhaps there needs to be a way to have libpam do the right thing. > In any case pam_user_policy seems under specfied. I don't agree. This module could be the first module in a stack, as 'binding', thus the ability to return PAM_IGNORE is quite useful. > > DOCUMENTATION > > ------------- > > > > - New man pages will be added for pam_eval(3PAM) and > > pam_user_policy(5). See case repository. > > > > - The user_attr(4) and prof_attr(4) man pages will be modified to > > mention 'pam_policy' and reference pam_user_policy(5). See case > > repository. > > > > > > INTERFACE STABILITY AND RELEASE BINDINGS > > ---------------------------------------- > > > > Interface Stability Release Binding > > > > pam_eval(3PAM) Stable Minor/patch > > pam_user_policy(5) Stable Minor/patch > > config file names Stable Minor/patch > > config file semantics Stable Minor/patch > > config file contents Unstable Minor/patch > > If the names and file semantics are stable, there needs to > be man pages describing them that I believe need to be part > of this case. Without the man pages, I can't say I'm sure > that the names are approachable. (P.S. that's not a call for > UIRB invented names.) The man page for pam_user_policy(5) describes them. Whether each gets a separate man page or is aliased to pam_user_policy(5) I don't much care. Thanks, Nico -- From sacadmin Fri May 6 20:54:55 2005 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.11.21]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j473sss0004492; Fri, 6 May 2005 20:54:54 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j473spkH007294; Fri, 6 May 2005 20:54:51 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id j473sOdg013388; Fri, 6 May 2005 20:54:24 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id j473sOms013387; Fri, 6 May 2005 20:54:24 -0700 (PDT) Date: Fri, 6 May 2005 20:54:24 -0700 (PDT) From: Gary Winiger Message-Id: <200505070354.j473sOms013387@marduk.eng.sun.com> To: PSARC@sac.sfbay.sun.com, darrenm@sac.sfbay.sun.com, gww@marduk.eng.sun.com Cc: gww@eng.sun.com, nicolas.williams@sun.com Subject: Re: Per user Authentication Policy [PSARC/2005/275 Timeout: 05/04/2005] Status: RO Content-Length: 149 Lines: 5 After discussing this case with the owner, I agreed to mark it waiting need spec while the project team works their differences off line. Gary.. From sacadmin Tue May 10 20:07:11 2005 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j4B37Bs0016602 for ; Tue, 10 May 2005 20:07:11 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j4B376224440; Tue, 10 May 2005 20:07:06 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.175.66]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j4B375jg029989; Tue, 10 May 2005 20:07:05 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j4B37As0016597; Tue, 10 May 2005 20:07:10 -0700 (PDT) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9/Submit) id j4B3792s016596; Tue, 10 May 2005 20:07:09 -0700 (PDT) Date: Tue, 10 May 2005 20:07:09 -0700 (PDT) Message-Id: <200505110307.j4B3792s016596@sac.sfbay.sun.com> To: PSARC@sun.com Cc: Nicolas.Williams@sun.com, PSARC-coord@sun.com From: PSARC-coord@sun.com Subject: New PSARC Materials Submitted 2005/275 Per user Authentication Policy Content-type: text/plain Status: RO Content-Length: 1181 Lines: 25 New Materials submitted for PSARC 2005/275 Per user Authentication Policy Status: inception scheduled 05/18/2005 Files: /shared/sac/PSARC/2005/275/inception.materials/any.conf /shared/sac/PSARC/2005/275/inception.materials/common-interactive.conf /shared/sac/PSARC/2005/275/inception.materials/common-login.conf /shared/sac/PSARC/2005/275/inception.materials/common-non-interactive.conf /shared/sac/PSARC/2005/275/inception.materials/krb5-fallback-unix.conf /shared/sac/PSARC/2005/275/inception.materials/krb5.conf /shared/sac/PSARC/2005/275/inception.materials/ksvcs.conf /shared/sac/PSARC/2005/275/inception.materials/ldap.conf /shared/sac/PSARC/2005/275/inception.materials/pam_eval.man /shared/sac/PSARC/2005/275/inception.materials/PAM_POLICY /shared/sac/PSARC/2005/275/inception.materials/pam_user_policy.man /shared/sac/PSARC/2005/275/inception.materials/prof_attr.4.diffs /shared/sac/PSARC/2005/275/inception.materials/smprofile.1m.diffs /shared/sac/PSARC/2005/275/inception.materials/swg-jws.pdf /shared/sac/PSARC/2005/275/inception.materials/unix.conf /shared/sac/PSARC/2005/275/inception.materials/user_attr.4.diffs Please let me know if you have questions. - PSARC From sacadmin Wed May 11 15:05:16 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j4BM5Gs0004046 for ; Wed, 11 May 2005 15:05:16 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk.SFBay.Sun.COM [129.146.11.21]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j4BM58i22473; Wed, 11 May 2005 15:05:08 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j4BM57kH029288; Wed, 11 May 2005 15:05:07 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id j4BM4ZA3026332; Wed, 11 May 2005 15:04:35 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id j4BM4YfZ026331; Wed, 11 May 2005 15:04:34 -0700 (PDT) Date: Wed, 11 May 2005 15:04:34 -0700 (PDT) From: Gary Winiger Message-Id: <200505112204.j4BM4YfZ026331@marduk.eng.sun.com> To: PSARC-coord@sun.com, PSARC@sun.com Cc: Nicolas.Williams@sun.com Subject: Re: New PSARC Materials Submitted 2005/275 Per user Authentication Policy Status: RO Content-Length: 160 Lines: 6 > /shared/sac/PSARC/2005/275/inception.materials/swg-jws.pdf Just checking, this doesn't seem related to this case. Is it really part of the review? Gary.. From sacadmin Wed May 11 15:13:10 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j4BMDAs0005249 for ; Wed, 11 May 2005 15:13:10 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.31]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j4BMCxK14188; Wed, 11 May 2005 16:12:59 -0600 (MDT) Received: from Sun.COM (sr1-umpk-04.SFBay.Sun.COM [129.146.11.160]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4BMCwst298833; Wed, 11 May 2005 15:12:58 -0700 (PDT) Message-ID: <4282836A.7050405@Sun.COM> Date: Wed, 11 May 2005 15:12:58 -0700 From: Sherri Shieh Reply-To: Sherri.Shieh@Sun.COM User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Winiger CC: PSARC-coord@Sun.COM, PSARC@Sun.COM, Nicolas.Williams@Sun.COM Subject: Re: New PSARC Materials Submitted 2005/275 Per user Authentication Policy References: <200505112204.j4BM4YfZ026331@marduk.eng.sun.com> In-Reply-To: <200505112204.j4BM4YfZ026331@marduk.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Content-Length: 527 Lines: 22 I don't believe it is......sorry about that. I have removed it. - Sherri Gary Winiger wrote: >>/shared/sac/PSARC/2005/275/inception.materials/swg-jws.pdf > > > Just checking, this doesn't seem related to this case. > Is it really part of the review? > > Gary.. -- ========================================================= Sherri Shieh Sun Microsystems, Inc. Program Manager Email: sherri.shieh@sun.com Systems Architecture Phone: xxxxxxxxxxxxxxxxxxx =========================================================== From sacadmin Wed May 11 15:20:59 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j4BMKws0005790 for ; Wed, 11 May 2005 15:20:58 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j4BMKoK19298; Wed, 11 May 2005 16:20:50 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j4BMKnrD024834; Wed, 11 May 2005 17:20:49 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4BMKnqH024833; Wed, 11 May 2005 17:20:49 -0500 (CDT) Date: Wed, 11 May 2005 17:20:49 -0500 From: Nicolas Williams To: Gary Winiger Cc: PSARC-coord@sun.com, PSARC@sun.com Subject: Re: New PSARC Materials Submitted 2005/275 Per user Authentication Policy Message-ID: <20050511222049.GO22993@binky.Central.Sun.COM> References: <200505112204.j4BM4YfZ026331@marduk.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505112204.j4BM4YfZ026331@marduk.eng.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 244 Lines: 7 On Wed, May 11, 2005 at 03:04:34PM -0700, Gary Winiger wrote: > > /shared/sac/PSARC/2005/275/inception.materials/swg-jws.pdf > > Just checking, this doesn't seem related to this case. > Is it really part of the review? I did not send it... From sacadmin Mon May 16 16:44:30 2005 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j4GNiUs0010852 for ; Mon, 16 May 2005 16:44:30 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk.SFBay.Sun.COM [129.146.11.21]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j4GNiLQ23012; Mon, 16 May 2005 16:44:21 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j4GNiKkH016875; Mon, 16 May 2005 16:44:20 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id j4GNhfF9009026; Mon, 16 May 2005 16:43:41 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id j4GNhf4W009025; Mon, 16 May 2005 16:43:41 -0700 (PDT) Date: Mon, 16 May 2005 16:43:41 -0700 (PDT) From: Gary Winiger Message-Id: <200505162343.j4GNhf4W009025@marduk.eng.sun.com> To: PSARC-coord@sun.com, PSARC@sun.com Cc: Nicolas.Williams@sun.com Subject: Re: New PSARC Materials Submitted 2005/275 Per user Authentication Policy Status: RO Content-Length: 140 Lines: 6 > Files: For additional back ground on potential issues, I've added /shared/sac/PSARC/2005/275/inception.materials/RBACTrainWreck Gary.. From sacadmin Mon May 16 17:23:43 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j4H0Nhs0012729 for ; Mon, 16 May 2005 17:23:43 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j4H0NXl28658 for ; Mon, 16 May 2005 18:23:33 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j4H0NWr8021444; Mon, 16 May 2005 19:23:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4H0NWgt021443; Mon, 16 May 2005 19:23:32 -0500 (CDT) Date: Mon, 16 May 2005 19:23:31 -0500 From: Nicolas Williams To: Gary Winiger Cc: PSARC@sun.com Subject: Re: New PSARC Materials Submitted 2005/275 Per user Authentication Policy Message-ID: <20050517002331.GI1783@binky.Central.Sun.COM> References: <200505162343.j4GNhf4W009025@marduk.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505162343.j4GNhf4W009025@marduk.eng.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 637 Lines: 20 On Mon, May 16, 2005 at 04:43:41PM -0700, Gary Winiger wrote: > > Files: > > For additional back ground on potential issues, I've added > /shared/sac/PSARC/2005/275/inception.materials/RBACTrainWreck I would also add that SMC and smprofile have a number of obnoxious problems relating to authentication, like: - no getpeerucred()-based authentication, so one must always supply a password to admin local files, even when already authorized; - no GSS-based authentication, so one must always supply a password to remotely admin systems; - looking at the source code, I see duplication of crypt() and the like. Nico -- From sacadmin Mon May 16 17:38:52 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j4H0cps0012815 for ; Mon, 16 May 2005 17:38:52 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.45]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j4H0cgl05711; Mon, 16 May 2005 18:38:42 -0600 (MDT) Received: from 129.146.108.198 (braveheart.SFBay.Sun.COM [129.146.108.198]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4H0cgv1683250; Mon, 16 May 2005 17:38:42 -0700 (PDT) Subject: Re: New PSARC Materials Submitted 2005/275 Per user Authentication Policy From: Darren J Moffat To: Nicolas Williams Cc: Gary Winiger , PSARC@Sun.COM In-Reply-To: <20050517002331.GI1783@binky.Central.Sun.COM> References: <200505162343.j4GNhf4W009025@marduk.eng.sun.com> <20050517002331.GI1783@binky.Central.Sun.COM> Content-Type: text/plain Organization: Sun Microsystems, Inc. Message-Id: <1116290320.1870.50.camel@braveheart> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Date: Mon, 16 May 2005 17:38:40 -0700 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 834 Lines: 25 On Mon, 2005-05-16 at 17:23, Nicolas Williams wrote: > On Mon, May 16, 2005 at 04:43:41PM -0700, Gary Winiger wrote: > > > Files: > > > > For additional back ground on potential issues, I've added > > /shared/sac/PSARC/2005/275/inception.materials/RBACTrainWreck > > I would also add that SMC and smprofile have a number of obnoxious > problems relating to authentication, like: > > - no getpeerucred()-based authentication, so one must always supply a > password to admin local files, even when already authorized; > > - no GSS-based authentication, so one must always supply a password to > remotely admin systems; > > - looking at the source code, I see duplication of crypt() and the > like. All of which is great opinion fodder but IMO shouldn't be tagged on as extra work for this case. -- Darren J Moffat From sacadmin Mon May 16 17:44:41 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j4H0ies0012862 for ; Mon, 16 May 2005 17:44:40 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j4H0iUl08252; Mon, 16 May 2005 18:44:30 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j4H0iT4m021467; Mon, 16 May 2005 19:44:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j4H0iTU4021466; Mon, 16 May 2005 19:44:29 -0500 (CDT) Date: Mon, 16 May 2005 19:44:29 -0500 From: Nicolas Williams To: Darren J Moffat Cc: Gary Winiger , PSARC@Sun.COM Subject: Re: New PSARC Materials Submitted 2005/275 Per user Authentication Policy Message-ID: <20050517004429.GK1783@binky.Central.Sun.COM> References: <200505162343.j4GNhf4W009025@marduk.eng.sun.com> <20050517002331.GI1783@binky.Central.Sun.COM> <1116290320.1870.50.camel@braveheart> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1116290320.1870.50.camel@braveheart> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 341 Lines: 7 On Mon, May 16, 2005 at 05:38:40PM -0700, Darren J Moffat wrote: > All of which is great opinion fodder but IMO shouldn't be tagged > on as extra work for this case. Of course. I think this material should emphasize your point, more than anything else, for how can RBAC consumers be on the hook for fixing RBAC when it needs so much work? From sacadmin Thu May 19 15:20:16 2005 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j4JMKGs0011925 for ; Thu, 19 May 2005 15:20:16 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.31]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j4JMK3105947; Thu, 19 May 2005 16:20:03 -0600 (MDT) Received: from Sun.COM (sr1-umpk-13.SFBay.Sun.COM [129.146.11.187]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j4JMK3QR661347; Thu, 19 May 2005 15:20:03 -0700 (PDT) Message-ID: <428D1112.6010105@Sun.COM> Date: Thu, 19 May 2005 15:20:02 -0700 From: Sherri Shieh Reply-To: Sherri.Shieh@Sun.COM User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psarc@Sun.COM, Nicolas Williams , Darren J Moffat Subject: PSARC Meeting Minutes 05/18/2005 Inception: 2005/275 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Content-Length: 16305 Lines: 493 All PSARC meeting minutes are available and are inline. Audio files are available too: (1) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20050518.arcbiz/mp3 (2) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20050518.2005.275.inception.mp3 Sum up available at: http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20050518.html If you ahve any corrections/feedback, please direct them to me. Thanks, Sherri =================== SYSTEM ARCHITECTURE COUNCIL Platform Software ARC --------------------------------- PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507. 05/18/2005 MEETING MINUTES ============================================================== CORRECTIONS, additions, deletions to sherri.shieh@sun.com. Minutes are archived in sac.Eng:/sac/export/sac/Minutes/PSARC. ATTENDEES - Members: Joseph Kowalski: yes (on sabbatical) Glenn Skinner: yes Robert Berube (temp chair) yes Andy Rudoff: no (on sabbatical) John Danielson: no (on sabbatical) Rich McDougall: no Hideki Hiura: no (on sabbatical) Lisa Camesano: no (on sabbatical) James Carlson: yes Andrew Tucker: no (on sabbatical) Shudong Zhou: yes Bill Sommerfeld: yes Gary Winiger: yes Tim Marsland: no (on sabbatical) Ed Gould: yes Sherri Shieh: yes ATTENDEES- Interns: John McKernan: no (on sabbatical) Don Cragun: yes Peter Dennis: no Wyllys Ingersoll: no Rick Matthews: yes Alec Muffett: no James Falkner: no (on sabbatical) Kais Belgaied: yes Michael Walker: no Phil Harman: no Raju Yadati: no Calum Mackay yes Michael Speer no Ienup Sung no Cecilia Hu: no Brian Utterback yes GUESTS: Darren Moffat Nicolas Williams Sebatian --------------------------------------------------------------------------- AGENDA ------- 05/18/2005 10:00-10:10 project id 10:10-10:20 ARC Business 10:20-11:05 Inception: Per user Authentication Policy (2005/275) Submitter: Nicolas Williams Owner: Darren Moffat Interest: Nicolas.Williams@sun.com --------------------------------------------------------------------------- Case Anchors: 1) Case 1: Per user Authentication Policy (2005/275) =========================================================================== ARC BUSINESS -------------- - Fast tracks- 2005/103 Schumacher Viswanath Krishnamur waiting fast-track 05/12/2005 Michael Speer * waiting need spec from last week - Gary's question answered? * Gary: My question was not answered - it is edited in the IAM file * This will stay at waiting need spec until project team gets it done - Bob will ping the project team about this 2005/236 Shared Disk Support for NHAS Renaud Mitrich waiting fast-track 05/19/2005 Ed Gould * Ed will have the info in about a day or two * time extended 2005/237 Netra HAS SAF CLM API for Solaris Alejandro Lopez waiting fast-track 05/18/2005 Ed Gould * time extended for another week 2005/238 NHAS support for Solaris 10 Pablo Martikian waiting fast-track 05/20/2005 Ed Gould * time extended for another week 2005/240 External Addresses over IPMP for NHAS Alejandro Lopez waiting fast-track 05/19/2005 Ed Gould * time extended for another week 2005/274 Persistent audio mixer settings Darren Moffat waiting fast-track 05/11/2005 Darren Moffat * Approved last week 2005/281 MAP_NOOVERMAP option for mmap() Boris Ostrovsky waiting fast-track 5/11/2005 Bart Smaalders * Approved last week 2005/290 pktool(1) alternate token support Dina Nimeh waiting fast-track 05/17/2005 Darren Moffat * Approved 2005/293 passwd -s Stable parsable output Darren Moffat waiting fast-track 05/13/2005 Darren Moffat * Approved last week 2005/299 Modify /usr/bin/od and /usr/xpg4/bin/od Alexander Kaplan waiting fast-track 05/18/2005 Donald Cragun * Approved - Other Business - * Taxonomy issue - Joe has another proposal about this that he will send it out - Maybe certain sections should address certain issues. - Can we actually make a meaningful statement to the customers of what this means? - Has this been brought up to a higher level? * It's been brought up to the EMG level....it's been discussed but they're aren't any details right now. It doesn't seem that the field is understanding it right now, which means that we failed. * There has been a request to make Brian Utterback as a PSARC intern. Welcome Brian! =D - Works in the Internet group, etc. =========================================================================== Inception: Per user Authentication Policy (2005/275) Submitter: Nicolas Williams Owner: Darren Moffat Interest: Nicolas.Williams@sun.com SUMMARY ======== * Advice on adding all the user_attr keys to prof_attr (except maybe for type.) * The project team will fix all nits that were brought up. ISSUES ====== eg-1 pam_eval.man, pam_user_policy.man Does "/usr/lib/security" get prepended to paths that begin with "./"? * No * The documentation doesn't actually say this... - I would just say this explicitly. * It looks to see if the first character of the path name is a "/". If it starts with a ".", it is still relative. Is there a(nother) way to test configuration files before installing them? * No, there never has been with PAM and this case doesn't change that. eg-2 PAM_POLICY both user_attr(4) and prof_attr(4) are listed in most places, but only user_attr(4) is listed in the "BACKGROUND" section. Was this an oversight, or is there something subtle here? * Neither it is just short hand. * These are nits to take care of by the project team. eg-3 pam_user_policy.man Is there always a place to prompt for PAM_USER? If there is not, what happens? * That depends on what kind of converstaiton function the application provided. There is nothing new introduced by this case. Existing modules and applications already deal with this. eg-4 pam_user_policy.man I find the "RETURN VALUES" section difficult to understand. Perhaps that's because I don't really understand PAM, but perhaps the prose could be improved as well. * I believe that if you understand PAM this is pretty clear, you can't read this man page alone you need to already understand pam(5), pam_authenticate(3pam), etc. gw-0 pam_eval: There are multiple ways a PAM stack evaluation can complete. Is it true that only if all modules return PAM_IGNORE this will return PAM_IGNORE? What about optional success and optional failure of the evaluated PAM stack, or the stack from which pam_eval is called? Is the intent of pam_eval to be a partial answer as the include flag is, or a complete answer? If it is a complete answer, I miss seeing why PAM_IGNORE should be returned. Why shouldn't the default error be returned? Then, the caller can return that as a binding service module and be done with it. If it is a partial answer, must callers of pam_eval be placed on multiple places in the initiating PAM stack to deal with the current PAM stack semantics? * I'm trying to understand the symantics of pam_eval. * It can only be called from within the process stack already. * Nicolas: pam-eval is not optional or binding - the module that calls this maybe optional or binding. It is up to the module that calls pam_eval to make sure this happens. * Glenn: I think it would help if the project team provide examples of pam_eval. * Modules today don't know about their control flag. * Gary: I believe that this works for the policy case. But I'm concerned that it is not returning the right information right now. - Darren: Maybe we should make some changes with this. gw-1 Adding to usermod/useradd and smprofile, why not also rolemod/roleadd, smuser and smrole? Adding pam_policy to smc(1M) for prof_attr only, but can also be in user_attr. * usermod/rolemod are actually same source/binary so yes it is added there. smuser/smrole should be updated as well. gw-2 pam_user_policy: Should define the service module entry points and how each functions. For example The pam_use_policy module implements all the PAM service module functions and .... For a specific type, such as pam_sm_authenticate, it may discuss getting PAM_USER if not set. Why does pam_policy return PAM_IGNORE for calls other than pam_sm_authenticate() if PAM_USER is not set? Doesn't pam_policy also apply elsewhere? How is passwd handled with respect to prompting for PAM_USER, there's a pam_passwd_auth(5) module, will this be stacked above it? What are the implications for pam_smartcard(5)? Would pam_jcdi(5) be any different? What are the implications for pam_sunray? * pam_smartcard does not and never has supported password change. For now pam_jcdi(5) isn't being shipped the project was cancelled. This project doesn't changing anything for those modules though. They never were in the default stack anyway. As for pam_sunray - well we don't really know what it does because it was never ARC'd. There are no config files shipped with this case that include pam_jcdi or pam_sunray because they are not part of Solaris. As for pam_smartcard it isn't in any of the default configs included in this case because it requires significant admin setup for smartcard. pam_smartcard is also a useless toy and we may be annoucing EOF of it soon (but less not have that discussion here). The way it gets placed into the pam.conf today is to insert it at the top of the stack for dtlogin/dtsession/xscreensaver/xlock the smartcard(1m) command does that and it will still work today and in the future if pam_user_policy is in the default pam.conf. * Gary: We really need to communicate with Sunray on this issue as well. gw-2 (con't) Returning the default error if pam_eval returns PAM_IGNORE seems to require knowledge of the default values that knowledge is presently only coded into libpam. This seems like an obvious place to get out of sync. See gw-0. * pam_deny PSARC/2004/290 does that today. gw-3 Why shouldn't there be a policy.conf default for pam_policy key? That way admins don't need to try to merge one of the proposed *.conf files into the local pam.conf and the *.conf files can be replaced on upgrade should changes be necessary. * policy.conf doesn't scale it should have been in the nameserice. You also don't need a pam_policy key in policy.conf because that only provides the default and we already have that its call /etc/pam.conf * Gary: i think it's wrong to have to edit pam.conf but I don't think it'll hold up the case. gw-4 Why do the *.conf files need ".conf"? Perhaps, we could come up with more approachable names. * conistency with /etc/pam.conf and with the include case. Also if we ever introduce /etc/pam.d like Linux has (and I believe we need to) then we need a way to distinguish the two styles because the pam.conf syntax isn't structured enough to tell the two appart in some cases. * Gary: I still think it is icky naming. * This issue will be taken offline and discussed even more. Missing documentation for common-interactive, common-login, common-non-interactive, ksvcs. What's their interface taxonomy? It is really "pam_policy" or should it be "auth_policy" or "account_policy"? * It is in the case material: INTERFACE STABILITY AND RELEASE BINDINGS ---------------------------------------- Interface Stability Release Binding pam_eval(3PAM) Stable Minor/patch pam_user_policy(5) Stable Minor/patch config file names Stable Minor/patch config file semantics Stable Minor/patch config file contents Unstable Minor/patch It is really "pam_policy" or should it be "auth_policy" or "account_policy"? * Any of those would do, however the word pam is in there because this only applies with PAM and not with GSS or SASL. * Gary: In the man page, you list the stability of all these things but I think this is the wrong place to have them. - This should be left to the tech writer then, since it doesn't deal with the actual arch structure. gw-5 UIRB? * Review of what? * Darren: Does the ARC really believe that this will help if this is sent to UIRB for review? - I think everyone agrees that this can be done as a self review. gw-6 NITs: prof_attr.4.diffs: pam_policy is described in user_attr(4) and pam_user_policy(5). Please describe completely in only one place. Don't split the description across man pages. missing *.conf man pages pam_eval.man: DESCRIPTION pam_eval() evaluates the current service and module type entries from conf_path and evaluates the PAM stack defined there. conf_path has the same format as pam_conf(4). If the path name is not absolute, it is assumed to be relative to /usr/lib/security. . . . RETURN VALUES pam_eval() returns the PAM return code produced by evaluating the PAM stack's service modules. pam_user_policy.man: Should also say something like: "pam_policy() implements all the PAM service module functions. ..." "pam_sm_authenticate() calls pam_get_user() with the default prompt to get the value of PAM_USER. ... " What options does this module take? Please have a ``debug'' option. Interface Stability *.conf really seems to belong on their individual man pages. gw-7 TCA add all the user_attr keys to prof_attr (except maybe for type.) Add new function char *getuservalue(const char *keyname, const char *username) to libsecdb to walk the user_attr, prof_attr and policy.conf databases (file) to extract the value for a given keyname. * Not this case this needs much more design than this. * Darren: I don't think this should be a TCA - I think that this is more advice. Update smc(1M) for all user_attr keys in prof_attr * Why should this case be burdened with the sloppy work of previous ones that didn't update smc(1m) ? gw-8 SC/PAC advice, do something positive about providing an extensible interface for extended user attributes (in such a way as to be sustainable and avoid train wrecks). See also: 6255542 "Lack of staffing inhibits innovation in user extended attributes" * Which is exactly why I'm saying that the suggested TCA in gw-7 is not appropriate for this case. Advice is appropriate. Whats more we still need direction from the Solaris PAC on what our Solaris management interface is supposed to be. wes-1 "krb5.conf" name collides in its leaf name with file used to configure kerberos itself. suggest naming the files in /usr/lib/security as pam-krb5.conf, pam-foo.conf, etc. * This issue has been discussed above already. wes-2 RBACTrainWreck: use of "keys" here is ambiguous/confusing. it looks like the only true lookup key for the user_attr database as a whole is the user login name, and the other things referred to as "keys" are per-user named attributes. (it may be consistent with the *_attr documentation but is inconsistent with the common use of "key" and thus a definition would be helpful) * BillS: This is just a writing suggestion. - This will be cleared up in the next review. NEXT STEP ========= * The project team will go back and resolve any issues/recommendations that were brought up during today's review. -- ========================================================= Sherri Shieh Sun Microsystems, Inc. Program Manager Email: sherri.shieh@sun.com Systems Architecture Phone: xxxxxxxxxxxxxxxxxxx =========================================================== From sacadmin Wed Jan 25 14:19:28 2006 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0PMJRIQ023992 for ; Wed, 25 Jan 2006 14:19:27 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k0PMHMWR007818; Wed, 25 Jan 2006 14:17:22 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k0PMHMk5007817; Wed, 25 Jan 2006 14:17:22 -0800 (PST) Date: Wed, 25 Jan 2006 14:17:22 -0800 (PST) From: Gary Winiger Message-Id: <200601252217.k0PMHMk5007817@marduk.eng.sun.com> To: psarc@sac.eng.sun.com Subject: 2005/275 Per User Authentication Policy materials Cc: nicolas.williams@sun.com, darren.moffat@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 508 Lines: 10 Jim's mail reminded me to send this out. I'd put commitment materials in this case directory in July as collaborative work with the project team. If you picked up these materials, they are not the correct materials. I've renamed that directory to avoid confusion. The project team called me yesterday about some finishing touches (what errors to return in corner cases) and said the materials would be coming last night or this morning. Project team, please take this as a ping to send materials. Gary.. From sacadmin Wed Jan 25 14:23:13 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0PMNCIQ024133 for ; Wed, 25 Jan 2006 14:23:12 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k0PMNBsj013884; Wed, 25 Jan 2006 16:23:11 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k0PMNBtq013883; Wed, 25 Jan 2006 16:23:11 -0600 (CST) Date: Wed, 25 Jan 2006 16:23:11 -0600 From: Nicolas Williams To: Gary Winiger Cc: psarc@sac.eng.sun.com, Darren.Moffat@Sun.COM Subject: Re: 2005/275 Per User Authentication Policy materials Message-ID: <20060125222311.GI26500@binky.Central.Sun.COM> References: <200601252217.k0PMHMk5007817@marduk.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601252217.k0PMHMk5007817@marduk.eng.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 655 Lines: 14 On Wed, Jan 25, 2006 at 02:17:22PM -0800, Gary Winiger wrote: > Jim's mail reminded me to send this out. I'd put commitment materials > in this case directory in July as collaborative work with the project team. > If you picked up these materials, they are not the correct materials. > I've renamed that directory to avoid confusion. The project team called > me yesterday about some finishing touches (what errors to return in corner > cases) and said the materials would be coming last night or this morning. > > Project team, please take this as a ping to send materials. I sent three updated files at 1:05PST to psarc-materials@sun.com. Nico -- From sacadmin Wed Jan 25 14:52:59 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0PMqwIQ024800 for ; Wed, 25 Jan 2006 14:52:58 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k0PMqwW27167; Wed, 25 Jan 2006 14:52:58 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0ITO00E057K90200@brm-avmta-1.central.sun.com>; Wed, 25 Jan 2006 15:52:57 -0700 (MST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0ITO00AUT7K8CY60@brm-avmta-1.central.sun.com>; Wed, 25 Jan 2006 15:52:57 -0700 (MST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.175.66]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k0PMquTe026783; Wed, 25 Jan 2006 14:52:56 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0PMqtIQ024794; Wed, 25 Jan 2006 14:52:55 -0800 (PST) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9/Submit) id k0PMqtA8024793; Wed, 25 Jan 2006 14:52:55 -0800 (PST) Date: Wed, 25 Jan 2006 14:52:55 -0800 (PST) From: PSARC-coord@sun.com Subject: New PSARC Materials Submitted 2005/275 Per user Authentication Policy To: PSARC@sun.com Cc: Nicolas.Williams@sun.com, PSARC-coord@sun.com Message-id: <200601252252.k0PMqtA8024793@sac.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.1.222179 Status: RO Content-Length: 365 Lines: 12 New Materials submitted for PSARC 2005/275 Per user Authentication Policy Status: commitment scheduled 02/01/2006 Files: /shared/sac/PSARC/2005/275/commitment.materials/pam_eval.3pam /shared/sac/PSARC/2005/275/commitment.materials/pam_user_policy.5 /shared/sac/PSARC/2005/275/commitment.materials/specification Please let me know if you have questions. - PSARC From sacadmin Wed Jan 25 15:44:28 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0PNiSIQ025973 for ; Wed, 25 Jan 2006 15:44:28 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k0PNiR812588 for <@sunmail3.sfbay.sun.com:psarc@sun.com>; Wed, 25 Jan 2006 15:44:27 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0ITO008079Y21800@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Wed, 25 Jan 2006 15:44:26 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0ITO006P89XY1W30@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Wed, 25 Jan 2006 15:44:22 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k0PNiMPu014018 for ; Wed, 25 Jan 2006 17:44:22 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k0PNiMSY014017 for psarc@sun.com; Wed, 25 Jan 2006 17:44:22 -0600 (CST) Date: Wed, 25 Jan 2006 17:44:22 -0600 From: Nicolas Williams Subject: PSARC 2005/275 commitment -- what changed To: psarc@sun.com Message-id: <20060125234422.GO26500@binky.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.1.1.222179 User-Agent: Mutt/1.5.7i Status: RO Content-Length: 332 Lines: 13 Changes since inception: - pam_eval(3PAM) will be Stable - pam_eval(3PAM) return values were finessed - pam_user_policy(5) man page has sections for the different service modules - pam_user_policy(5) prompting for username in auth service module is documented - pam_user_policy(5) return values were finessed Nico -- From sacadmin Mon Jan 30 08:42:47 2006 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0UGglIQ003875 for ; Mon, 30 Jan 2006 08:42:47 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k0UGh2Ji015252; Mon, 30 Jan 2006 08:43:02 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k0UGh2M3015251; Mon, 30 Jan 2006 08:43:02 -0800 (PST) Date: Mon, 30 Jan 2006 08:43:02 -0800 (PST) From: Gary Winiger Message-Id: <200601301643.k0UGh2M3015251@marduk.eng.sun.com> To: psarc@sac.eng.sun.com Subject: 2005/275 Per user Authentication Policy materials update Cc: nicolas.williams@sun.com, darren.moffat@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 625 Lines: 15 I noticed this morning that we forgot to include policy.conf(4) changes in the commitment materials. I've place a diff marked draft of that man page in the commitment materials. The change is the following paragraph: + PAM_POLICY + Specify the default name (or path name) of the PAM + configuration file (see user_policy(5)) to be used for + user's without an explicitly defined in prof_attr(4) / + user_attr(4) PAM policy. PAM_POLICY is only effective + where pam_user_policy(5) is configured within the PAM + configuration. Sorry for any inconvenience. Gary.. From sacadmin Mon Jan 30 08:54:43 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0UGsgIQ004964 for ; Mon, 30 Jan 2006 08:54:43 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k0UGsfnu024497; Mon, 30 Jan 2006 10:54:41 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k0UGsdxQ024496; Mon, 30 Jan 2006 10:54:39 -0600 (CST) Date: Mon, 30 Jan 2006 10:54:39 -0600 From: Nicolas Williams To: Gary Winiger Cc: psarc@sac.eng.sun.com, Darren.Moffat@Sun.COM Subject: Re: 2005/275 Per user Authentication Policy materials update Message-ID: <20060130165438.GR20459@binky.Central.Sun.COM> References: <200601301643.k0UGh2M3015251@marduk.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601301643.k0UGh2M3015251@marduk.eng.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 854 Lines: 18 On Mon, Jan 30, 2006 at 08:43:02AM -0800, Gary Winiger wrote: > I noticed this morning that we forgot to include policy.conf(4) changes > in the commitment materials. I've place a diff marked draft of that > man page in the commitment materials. The change is the following paragraph: > > + PAM_POLICY > + Specify the default name (or path name) of the PAM > + configuration file (see user_policy(5)) to be used for > + user's without an explicitly defined in prof_attr(4) / > + user_attr(4) PAM policy. PAM_POLICY is only effective > + where pam_user_policy(5) is configured within the PAM > + configuration. > > Sorry for any inconvenience. Hm, did I get confused? I thought pam_user_policy would look for 'pam_policy' in the default granted profiles if a user had no user_attr(4) entry. From sacadmin Mon Jan 30 09:05:43 2006 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0UH5gIQ005158 for ; Mon, 30 Jan 2006 09:05:42 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k0UH5v12015323; Mon, 30 Jan 2006 09:05:57 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k0UH5vsu015322; Mon, 30 Jan 2006 09:05:57 -0800 (PST) Date: Mon, 30 Jan 2006 09:05:57 -0800 (PST) From: Gary Winiger Message-Id: <200601301705.k0UH5vsu015322@marduk.eng.sun.com> To: gww@eng.sun.com, Nicolas.Williams@Sun.COM Subject: Re: 2005/275 Per user Authentication Policy materials update Cc: psarc@sac.eng.sun.com, Darren.Moffat@Sun.COM X-Sun-Charset: US-ASCII Status: RO Content-Length: 553 Lines: 16 > > Sorry for any inconvenience. > > Hm, did I get confused? I thought pam_user_policy would look for > 'pam_policy' in the default granted profiles if a user had no > user_attr(4) entry. Sorry I mis-read. Nico is right, please disregard my blunder. The materials say: - A new PAM module, pam_user_policy(5) which looks up the PAM_USER's 'pam_policy' effective user attribute by searching user_attr(4) for the 'pam_policy' key, then the profiles in order specified and finally the default profiles specified in policy.conf(4). Gary.. From sacadmin Mon Feb 6 02:42:50 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k16AgmIQ009691 for ; Mon, 6 Feb 2006 02:42:49 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k16AgbDj019088 for <@sunmail1brm.central.sun.com:psarc@Sun.COM>; Mon, 6 Feb 2006 18:42:47 +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 <0IU900F01HR96A00@brm-avmta-1.central.sun.com> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Mon, 06 Feb 2006 03:42:45 -0700 (MST) Received: from nis-uk.uk.sun.com ([129.156.85.41]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IU90074AHR7JK60@brm-avmta-1.central.sun.com> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Mon, 06 Feb 2006 03:42:45 -0700 (MST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k16AgfoR016070; Mon, 06 Feb 2006 10:42:41 +0000 (GMT) Received: from 129.156.173.21 (enoexec [129.156.173.21]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k16Ageu3004722; Mon, 06 Feb 2006 10:42:40 +0000 (GMT) Date: Mon, 06 Feb 2006 10:42:40 +0000 From: Darren J Moffat Subject: [Opinion Review ] PSARC/2005/275 Per user Authentication Policy To: psarc@Sun.COM Cc: Nicolas Williams Message-id: <1139222560.978332.49.camel@enoexec> Organization: Sun Microsystems, Inc. MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.331 Content-type: multipart/mixed; boundary="Boundary_(ID_BdhiRTZB43TF9Au+nLLCgA)" X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 1042 Lines: 33 --Boundary_(ID_BdhiRTZB43TF9Au+nLLCgA) Content-type: text/plain Content-transfer-encoding: 7BIT Attached is the PDF opinion for review. There is an html copy in the case directory as well. http://sac.sfbay.sun.com/PSARC/2005/275/opinion.html I think I'm missing a member name in the list of approvers. Time out for review comments is Monday 13th Feb 2006. Please don't complain about the lack of a text opinion, the default template generated by the sac tools is html. There is no sac tool for generating a text opinion from the default html template. Either place such a tool in /shared/sac/bin or run a case to EOF the use of html as an acceptable opinion format. -- Darren J Moffat --Boundary_(ID_BdhiRTZB43TF9Au+nLLCgA) Content-Type: message/external-body; access-type=x-mutt-deleted; expiration="Fri, 26 Sep 2008 15:34:20 -0500"; length=76778 Content-type: application/pdf; name=opinion.pdf Content-transfer-encoding: base64 Content-disposition: attachment; filename=opinion.pdf --Boundary_(ID_BdhiRTZB43TF9Au+nLLCgA)-- From sacadmin Mon Feb 6 04:09:31 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k16C9UIQ011555 for ; Mon, 6 Feb 2006 04:09:30 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k16C9PC20693; Mon, 6 Feb 2006 04:09:25 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0IU900D01LRODY00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 06 Feb 2006 04:09:24 -0800 (PST) Received: from phorcys.East.Sun.COM ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IU9004NPLRONN90@nwk-avmta-1.sfbay.Sun.COM>; Mon, 06 Feb 2006 04:09:24 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k16C9Ng9118140; Mon, 06 Feb 2006 07:09:23 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k16C9N6g118137; Mon, 06 Feb 2006 07:09:23 -0500 (EST) Date: Mon, 06 Feb 2006 07:09:23 -0500 From: James Carlson Subject: Re: [Opinion Review ] PSARC/2005/275 Per user Authentication Policy In-reply-to: Darren J Moffat's message of 6 February 2006 10:42:40 To: Darren J Moffat Cc: psarc@sun.com, Nicolas Williams Message-id: <17383.15475.799098.183730@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 References: <1139222560.978332.49.camel@enoexec> Status: RO Content-Length: 1037 Lines: 26 Darren J Moffat writes: > http://sac.sfbay.sun.com/PSARC/2005/275/opinion.html There's an "XXX" comment in the text. This probably needs to be cleaned up for review. (Also, most of the references appear as plain text, though it looks like they were meant to be links.) The PAC email address is set to "${PACemail}," which is unlikely to work. Because the advice is extracted textually for the PAC, these items need to be complete in themselves, and not just say "see section blah." Nit: please don't invent a new date format for the ARC. I realize it's unfortunate that we have the format we do, but starting a new tradition here (without having other documents adopt the same) doesn't sound like a good plan to me. I'd quote the sections needing attention, but you didn't provide plain text as required. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon Feb 6 06:00:25 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k16E0NIQ013488 for ; Mon, 6 Feb 2006 06:00:24 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k16E0Aja004358 for <@sunmail1brm.central.sun.com:psarc@Sun.COM>; Mon, 6 Feb 2006 22:00:22 +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 <0IU90000BQWDCP00@brm-avmta-1.central.sun.com> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Mon, 06 Feb 2006 07:00:13 -0700 (MST) Received: from nis-uk.uk.sun.com ([129.156.85.41]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IU9007H3QWCJOB0@brm-avmta-1.central.sun.com> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Mon, 06 Feb 2006 07:00:13 -0700 (MST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k16E08oR015687; Mon, 06 Feb 2006 14:00:09 +0000 (GMT) Received: from 129.156.173.21 (enoexec [129.156.173.21]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k16E08H9019965; Mon, 06 Feb 2006 14:00:08 +0000 (GMT) Date: Mon, 06 Feb 2006 14:00:08 +0000 From: Darren J Moffat Subject: Re: [Opinion Review ] PSARC/2005/275 Per user Authentication Policy In-reply-to: <17383.15475.799098.183730@gargle.gargle.HOWL> To: James Carlson Cc: psarc@sun.com, Nicolas Williams Message-id: <1139234408.978332.53.camel@enoexec> Organization: Sun Microsystems, Inc. MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.331 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 References: <1139222560.978332.49.camel@enoexec> <17383.15475.799098.183730@gargle.gargle.HOWL> Status: RO Content-Length: 1246 Lines: 39 On Mon, 2006-02-06 at 12:09, James Carlson wrote: > Darren J Moffat writes: > > http://sac.sfbay.sun.com/PSARC/2005/275/opinion.html > > There's an "XXX" comment in the text. This probably needs to be > cleaned up for review. (Also, most of the references appear as plain > text, though it looks like they were meant to be links.) fixed. > The PAC email address is set to "${PACemail}," which is unlikely to > work. fixed, that looks like a bug or missing feature in the shell script that generates the template. > Because the advice is extracted textually for the PAC, these items > need to be complete in themselves, and not just say "see section > blah." Since the detail of this is quite long I've added a full reference the the file that discusses it. > Nit: please don't invent a new date format for the ARC. I realize > it's unfortunate that we have the format we do, but starting a new > tradition here (without having other documents adopt the same) doesn't > sound like a good plan to me. Force of habit, fixed to American format. > I'd quote the sections needing attention, but you didn't provide plain > text as required. You didn't need to the narrative text of your comments was perfectly clear. -- Darren J Moffat From sacadmin Mon Feb 6 09:48:52 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k16HmpIQ019677 for ; Mon, 6 Feb 2006 09:48:51 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k16HmXc04241; Mon, 6 Feb 2006 10:48:33 -0700 (MST) 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 <0IUA0090Z1GW0U00@brm-avmta-1.central.sun.com>; Mon, 06 Feb 2006 10:48:32 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.224.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IUA006HT1GVG050@brm-avmta-1.central.sun.com>; Mon, 06 Feb 2006 10:48:31 -0700 (MST) Received: from [129.150.27.59] (vpn-129-150-27-59.SFBay.Sun.COM [129.150.27.59]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k16HmUif681383; Mon, 06 Feb 2006 09:48:30 -0800 (PST) Date: Mon, 06 Feb 2006 09:48:34 -0800 From: Sherri Shieh Subject: PSARC Meeting Minutes 02/01/2006 Commitment: 2005/275; Inception: 2004/750; Inception: 2005/707 To: psarc@sun.com, Nicolas Williams , Johnny Hui , Darren J Moffat , Roman Zajcew Reply-to: sherri.shieh@sun.com Message-id: <43E78BF2.9010901@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.1.2.240295 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 1301 Lines: 42 All, Meeting minutes for 02/01/2006 are now available and are attached. Audio files are available as well: (1) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060201.arcbiz.mp3 (2) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060201.2005.275.commitment.mp3 (3) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060201.2004.750.inception.mp3 (4) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060201.2005.707.inception.mp3 Sum up available at: http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060201.html If you have any questions/corrections, please direct them to me. Thanks, Sherri -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherri Shieh Program Manager, Systems Architecture Sun Microsystems, Inc. Phone: xxxxxxxxxxxxxxxxxxx Email: Sherri.Shieh@sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From sacadmin Fri Feb 10 13:09:17 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1AL9HIQ012983 for ; Fri, 10 Feb 2006 13:09:17 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1AL9HB04273 for <@sunmail2.sfbay.sun.com:psarc@Sun.COM>; Fri, 10 Feb 2006 13:09:17 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0IUH0000DPFDTW00@nwk-avmta-1.sfbay.Sun.COM> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Fri, 10 Feb 2006 13:09:13 -0800 (PST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IUH00EXSPFDA470@nwk-avmta-1.sfbay.Sun.COM> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Fri, 10 Feb 2006 13:09:13 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k1AL9AmT007717; Fri, 10 Feb 2006 13:09:10 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k1AL90V3024471; Fri, 10 Feb 2006 13:09:00 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k1AL90Vr024470; Fri, 10 Feb 2006 13:09:00 -0800 (PST) Date: Fri, 10 Feb 2006 13:09:00 -0800 (PST) From: Gary Winiger Subject: Re: [Opinion Review ] PSARC/2005/275 Per user Authentication Policy To: Darren.Moffat@Sun.COM, psarc@Sun.COM Cc: Nicolas.Williams@Sun.COM Message-id: <200602102109.k1AL90Vr024470@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 826 Lines: 22 > Attached is the PDF opinion for review. There is an html > copy in the case directory as well. > > http://sac.sfbay.sun.com/PSARC/2005/275/opinion.html I don't know what you used for a PDF converter, but it turned it into on page of printed output at 4/6pt type. Perhaps there's a way to pagenate the output. I think Jim picked up the real comments. > Please don't complain about the lack of a text opinion, the default > template generated by the sac tools is html. There is no sac tool for > generating a text opinion from the default html template. Either place > such a tool in /shared/sac/bin or run a case to EOF the use of html as > an acceptable opinion format. I ran /shared/sac/bin/elinks -dump -no-numbering file://./opinion.html and produced a readable, though not pagenated opinion.txt. Gary.. From sacadmin Mon Feb 13 01:35:59 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1D9ZxIQ015218 for ; Mon, 13 Feb 2006 01:35:59 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1D9ZxU19484 for <@sunmail3.sfbay.sun.com:psarc@Sun.COM>; Mon, 13 Feb 2006 01:35:59 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0IUM0050FDBXJ400@nwk-avmta-2.sfbay.sun.com> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Mon, 13 Feb 2006 01:35:57 -0800 (PST) Received: from nis-uk.uk.sun.com ([129.156.85.41]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IUM00BJMDBT6KA0@nwk-avmta-2.sfbay.sun.com> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Mon, 13 Feb 2006 01:35:54 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k1D9ZnoR018685; Mon, 13 Feb 2006 09:35:50 +0000 (GMT) Received: from [129.156.173.199] (estale [129.156.173.199]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k1D9Zn9m022603; Mon, 13 Feb 2006 09:35:49 +0000 (GMT) Date: Mon, 13 Feb 2006 09:35:49 +0000 From: Darren J Moffat Subject: Re: [Opinion Review ] PSARC/2005/275 Per user Authentication Policy In-reply-to: <200602102109.k1AL90Vr024470@marduk.eng.sun.com> To: Gary Winiger Cc: psarc@Sun.COM, Nicolas.Williams@Sun.COM Message-id: <43F052F5.1080301@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 References: <200602102109.k1AL90Vr024470@marduk.eng.sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 396 Lines: 16 Gary Winiger wrote: >> Attached is the PDF opinion for review. There is an html >> copy in the case directory as well. >> >> http://sac.sfbay.sun.com/PSARC/2005/275/opinion.html >> > > I don't know what you used for a PDF converter, > but it turned it into on page of printed output > at 4/6pt type. Perhaps there's a way to pagenate > the output. > StarOffice. -- Darren J Moffat From sacadmin Mon Feb 13 07:42:30 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1DFgUIQ022655 for ; Mon, 13 Feb 2006 07:42:30 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1DFgTT09899 for <@sunmail3.sfbay.sun.com:psarc@Sun.COM>; Mon, 13 Feb 2006 08:42:29 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0IUM00K05UARRE00@nwk-avmta-2.sfbay.sun.com> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Mon, 13 Feb 2006 07:42:27 -0800 (PST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IUM00G0IUAOP040@nwk-avmta-2.sfbay.sun.com> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Mon, 13 Feb 2006 07:42:24 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k1DFgLmT019031; Mon, 13 Feb 2006 07:42:21 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k1DFg7Ho027443; Mon, 13 Feb 2006 07:42:07 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k1DFg7i0027442; Mon, 13 Feb 2006 07:42:07 -0800 (PST) Date: Mon, 13 Feb 2006 07:42:07 -0800 (PST) From: Gary Winiger Subject: Re: [Opinion Review ] PSARC/2005/275 Per user Authentication Policy To: gww@eng.sun.com, Darren.Moffat@Sun.COM Cc: psarc@Sun.COM, Nicolas.Williams@Sun.COM Message-id: <200602131542.k1DFg7i0027442@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 139 Lines: 7 > >> http://sac.sfbay.sun.com/PSARC/2005/275/opinion.html > StarOffice. I'll try Safari print to PDF when I get in later today. Gary.. From sacadmin Mon Feb 13 09:41:26 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1DHfQIQ027777 for ; Mon, 13 Feb 2006 09:41:26 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1DHfM314970 for <@sunmail2.sfbay.sun.com:psarc@sun.com>; Mon, 13 Feb 2006 09:41:22 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0IUM0000BZSXC700@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 13 Feb 2006 09:41:21 -0800 (PST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IUM00EO4ZSW9V55@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 13 Feb 2006 09:41:20 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k1DHfImT003104; Mon, 13 Feb 2006 09:41:18 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k1DHf4eB027658; Mon, 13 Feb 2006 09:41:04 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k1DHf4p8027657; Mon, 13 Feb 2006 09:41:04 -0800 (PST) Date: Mon, 13 Feb 2006 09:41:04 -0800 (PST) From: Gary Winiger Subject: Re: [Opinion Review ] PSARC/2005/275 Per user Authentication Policy To: gww@eng.sun.com, Darren.Moffat@sun.com Cc: psarc@sun.com, Nicolas.Williams@sun.com Message-id: <200602131741.k1DHf4p8027657@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 268 Lines: 10 > > >> http://sac.sfbay.sun.com/PSARC/2005/275/opinion.html > > > StarOffice. > > I'll try Safari print to PDF when I get in later today. I converted with Safari and print to PDF. It's not perfect, but it is readable. Previous saved as old.opinion.pdf Gary.. From sacadmin Thu Sep 25 21:00:00 2008 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 m8Q3xx0U017798 for ; Thu, 25 Sep 2008 21:00:00 -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 m8Q3xu3C006205 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Fri, 26 Sep 2008 11:59:58 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7S00H01B3YYL00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 25 Sep 2008 20:59:58 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.107]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7S009V3B3XD060@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 25 Sep 2008 20:59:57 -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 m8Q3xgPr022103 for ; Thu, 25 Sep 2008 22:59:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m8Q3xgDJ022102 for psarc@sun.com; Thu, 25 Sep 2008 22:59:42 -0500 (CDT) Date: Thu, 25 Sep 2008 22:59:42 -0500 From: Nicolas Williams Subject: PSARC/2005/275 updates To: psarc@sun.com Message-id: <20080926035942.GB9765@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 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: 1564 Lines: 42 I'd like to record the following updates to this case: 1) PSARC/2007/401 (kclient v2) added pam.conf includeable snippets in /usr/lib/security/pam_krb5_{only, first, optional}. PSARC/2005/275 had committed to delivering equivalents files named /usr/lib/security/krb5, etcetera. Since PSARC/2007/401 has delivered we'll rename all the pam.conf snippet files in /usr/lib/security to have a 'pam_' prefix. The complete list will be: /usr/lib/security/pam_krb5_first (from PSARC/2007/401) /usr/lib/security/pam_krb5_only (from PSARC/2007/401) /usr/lib/security/pam_krb5_optional (from PSARC/2007/401) /usr/lib/security/pam_unix_only /usr/lib/security/pam_unix_or_ldap /usr/lib/security/pam_ldap_only 2) The original TCR that SMC had to be modified to understand the pam_policy attribute, and to have GUI elements for it has been withdrawn (c.f. Gary Winiger). (As a result of this I'm now able to deliver the implementation to ONNV.) Also, I think we'll want to run a future case to make the default /etc/pam.conf use pam_user_policy(5) and to modify the OpenSolaris installer to set pam_policy=pam_unix_only for the local user account created during installation. Once enough of this case is opened we could discuss such a future enhancement on security-discuss. We may also want to modify kclient(1M) to configure the policy given with kclient's -s option as the default pam_policy for all users. Again, we may want to discuss this on security-discuss once this case is opened. Nico -- From sacadmin Fri Oct 10 12:41:23 2008 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 m9AJfNqr000745 for ; Fri, 10 Oct 2008 12:41:23 -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 m9AJfNhh018668 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Fri, 10 Oct 2008 12:41:23 -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 <0K8J0040LG0YYJ00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 10 Oct 2008 12:41:22 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8J002WUG0WQB20@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 10 Oct 2008 12:41:20 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9AJfKdg040068; Fri, 10 Oct 2008 12:41:20 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m9AJgLQA014238; Fri, 10 Oct 2008 12:42:21 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m9AJgLYL014237; Fri, 10 Oct 2008 12:42:21 -0700 (PDT) Date: Fri, 10 Oct 2008 12:42:21 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC/2005/275 updates To: psarc@Sun.COM, Nicolas.Williams@Sun.COM Message-id: <200810101942.m9AJgLYL014237@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 941 > 2) The original TCR that SMC had to be modified to understand the > pam_policy attribute, and to have GUI elements for it has been > withdrawn (c.f. Gary Winiger). Indeed at the time I made these comments to Nico, I had been told by my management that SMC was no longer going to be a necessary administrative interface for the RBAC databases. Subsequent to that time there has seemed to be significant management push to require changes to SMC for the RBAC databases. Shortly after this was posted, I've communicated that as well to Nico. So things seem to be back on hold. I'm finally getting around to recording this communication in the case log. I'm going back to management for clarification. I may have been confused in what was meant. Their comments may have only applied to a minor release. This case has a patch release binding. I'll update Nico and the case log as soon as I get clarification. Gary.. From sacadmin Fri Oct 10 12:43:13 2008 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 m9AJhCa4000804 for ; Fri, 10 Oct 2008 12:43:13 -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 m9AJgrJt009706 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Sat, 11 Oct 2008 03:43:11 +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 <0K8J0040BG3WOV00@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 10 Oct 2008 13:43:08 -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 <0K8J007WRG3UMUD0@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 10 Oct 2008 13:43:06 -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 m9AJgkt2007909; Fri, 10 Oct 2008 14:42:46 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m9AJgkiT007908; Fri, 10 Oct 2008 14:42:46 -0500 (CDT) Date: Fri, 10 Oct 2008 14:42:46 -0500 From: Nicolas Williams Subject: Re: PSARC/2005/275 updates In-reply-to: <200810101942.m9AJgLYL014237@marduk.eng.sun.com> To: Gary Winiger Cc: psarc@Sun.COM Message-id: <20081010194246.GK8906@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: <200810101942.m9AJgLYL014237@marduk.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: 1168 On Fri, Oct 10, 2008 at 12:42:21PM -0700, Gary Winiger wrote: > > > 2) The original TCR that SMC had to be modified to understand the > > pam_policy attribute, and to have GUI elements for it has been > > withdrawn (c.f. Gary Winiger). > > Indeed at the time I made these comments to Nico, I had been told > by my management that SMC was no longer going to be a necessary > administrative interface for the RBAC databases. Subsequent to > that time there has seemed to be significant management push > to require changes to SMC for the RBAC databases. Shortly after > this was posted, I've communicated that as well to Nico. > So things seem to be back on hold. I'm finally getting around > to recording this communication in the case log. > > I'm going back to management for clarification. I may have been > confused in what was meant. Their comments may have only applied > to a minor release. This case has a patch release binding. > I'll update Nico and the case log as soon as I get clarification. Note that this case in no way breaks SMC. SMC will simply not be able to observe nor change this new user/profile attribute. Nico --