On Sat, 15 Sep 2001, Luke Howard wrote: > Really? Looking through the Darwin PAM sources, the following modules > support the use of some of or all of use_first_pass, try_first_pass, > use_mapped_pass and try_mapped_pass: > > pam_directoryservice > pam_kerberosIV > pam_keychain > pam_krb5 > pam_netinfo > pam_nis > pam_opie > pam_radius > pam_skey > pam_ssh > pam_tacplus > pam_tim > pam_unix > Add pam_pwdb. I'm just looking at the main Linux-PAM tarball. And from the 0.75 sources, pam_radius doesn't support any of those arguments. But these 2 issues are beside the point. These modules don't store this information in a consistant way after parsing. pam_unix (and pam_pwdb), for example, uses a single integer and a couple of macros with a single bit for each possible argument. There are so many possible arguments that there is simply no way of centralizing the parsing, or else there would be no argv-style arguments, PAM would simply convert them to flags and pass them in the 'flags' argument. The module writer's guide lists 6 options that must be accepted (not neccisarily used, though). Those are the only arguments that you could truely centralize, but I don't believe doing such a thing would make any significant impact. I see no benefit in doing this. Argument parsing is simply not a platform dependent operation and there are no thread-safety issues. I may have screwed up with syslog, but argument parsing definately doesn't belong in a utility library designed to make modules portable. - Adam Slattery
