On Mon, Dec 04, s_n wrote: > My first supprise writing this module was the variance between different > pam implementations, where each has some own extensions. In linux-pam > there are even differences between official pam library from kernel.org > and this one installed on linux distribution, which is claimed to be the > most secure one (maybe there are others as [k]ubuntu which base on this > distro). Knowing the patches most distributors are using, I know that this is not true. I guess what you are seeing is, that some distributions are shipping the latest release, while others are shipping older releases. This older releases do, of course, miss some of the new features. > This way PAM library will be in the future not only platform > dependent but also will depend on a goodwill of the given distro > developers, silly. If you use PAM implementation specific extensions, you will always have this problems. Look at the manual page of the functions and don't use such one which are marked as "Linux-PAM extensions". > The second thing which is interesting in its madness is passing and > reciving data between [pam_module <-> application <-> user]. > There is well known pam_conv(3) mechanism used in almost all pam > implementations but also there are dependent pam_prompt(3), pam_info(3), > pam_get_authtok(3) etc. pam_info has nothing to do with pam_conv, pam_prompt is only a higher level function (and Linux-PAM extension) or call it wrapper around pam_conv. pam_get_authtok(3) is a openpam extension, don't use extensions for portable code. > And here fun begins. Whatever function you'll > use it can behave different with different services (e.g. with ssh you > are able to display challenge and recive response via any function, but > with ftp you can do nothing about it, what is the reason?). The minimum level of what PAM can do is what the protocol allows. FTP protocol is very limited and does not allow what ssh allows. > To conclude somehow all my scribbles above: > - Is there any authority, which could set some standards about what > basic PAM libraries functionality should be? Yes, see the rfc86.0.txt and draft-morgan-pam-current.txt files of Linux-PAM and the documentation from the Opengroup. > - Are there poeple who can give their free time and contribute to create > some coherent pam docuentation which will be generic for the most > popular pam implementations (I would)? Is it worth of effort anyway? I don't see big differences between the manual pages of Solaris, OpenPAM and Linux-PAM for the main PAM functions. > - Is it reasonable to use pam extensions by pam module developers as > they are not mandatory to include into pam library by system/distro > developers? Depends on what you which to archive. > - Are there any suggestions about how to write independent pam module > without writing different versions for every pam library implementation? Use only the standard PAM functions, not such which are marked as extensions in the documentation. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@xxxxxxx SUSE LINUX Products GmbH Maxfeldstr. 5 D-90409 Nuernberg -------------------------------------------------------------------- Key fingerprint = 8C6B FD92 EE0F 42ED F91A 6A73 6D1A 7F05 2E59 24BB _______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
