Issues for inception: Per user Authentication Policy (2005/275) 18 May 2005 File Version: 1.6 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ eg-1 pam_eval.man, pam_user_policy.man Does "/usr/lib/security" get prepended to paths that begin with "./"? A: Yes, this is existing libpam behaviour. Is there a(nother) way to test configuration files before installing them? A: 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? A: It should be both. eg-3 pam_user_policy.man Is there always a place to prompt for PAM_USER? If there is not, what happens? A: 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. A: 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? 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. A: 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? A: 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. 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. A: 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. A: 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 gw-4 Why do the *.conf files need ".conf"? Perhaps, we could come up with more approachable names. A: 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. AI: determine if this can be done programatically or pick a unique prefix like pam_ Missing documentation for common-interactive, common-login, common-non-interactive, ksvcs. What's their interface taxonomy? A: 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"? A: any of those would do, however the word pam is in there because this only applies with PAM and not with GSS or SASL. gw-5 UIRB? A: Project team asserts self-review - PSARC agreed. 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.) A: Not in this case. 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. A: Not this case this needs much more design than this. Update smc(1M) for all user_attr keys in prof_attr A: 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" A: 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. A: as gw-4, resolve for commitment. 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) A: Gary will fix for commitment review. Key means attribute name not key as in database lookup index.