On Tue, May 15, 2001 at 01:29:16PM -0400, Nicolas Williams wrote: > On Tue, May 15, 2001 at 09:59:23AM -0700, Andrew Morgan wrote: > > I didn't quite follow your explanation before about this. But, it is > > already possible, with Linux-PAM, to specify effective > > forked-authentication chains: > > > > auth [success=2, default=reset] pam_user_in_arglist.so me you him her > > auth requisite pam_unix.so > > auth sufficient pam_permit.so > > Oh. Is this documented? I don't follow this example as it is... I.e., > where is the fork? Is the success=2 a "skip 2 if success" directive?? If > so, I'd love that sort of thing -- I might even write a patch for > Solaris PAM and submit it to sun in an RFE... Yes, it is documented. When was it added to Linux-PAM? Also, since the docs mention this along with binary prompts, I'd like to make a comment on binary prompts: it would be nice if the name of the module issuing a binary prompt and/or an optional token type were included in the binary prompt. I think PAM binary prompts could be used as a simple API wrapper around SASL/GSS-API/Kerberos/..., but apps using PAM this way might need to know the token types so as to, for example, be able to further format them as needed by the protocol spoken by the app, or to be able to respond appropriately to prompts whose token type cannot be used by the app, either because the protocols it speaks don't specify how to use certain token types, or because the app has negotiated a network authentication protocol to use with the remote side and so on... Also, to be truly useful as a simple wrapper around those complex APIs, PAM would have to provide a way for the app to communicate with the modules. But this should be in a separate thread, and we've been through this already, so maybe I should just let it die... :) Cheers, Nico --
