> > > > I primarily patched the latest version to obtain pathnames > > from environment variables. I also directed system logging > > to a file. My aim, however, was to modify the original PAM > > code as little as possible, since I want to reduce the > > possibility of introducing anomalous behaviors due to the > > changes themselves (is that Heisencode? :-). > > > > Great! I absolutely agree with the effort not to affect the ordinary > > PAM (the code used when PAM is integrated within system). Were the > modifications > > accepted into PAM project? Could you send me the code with your modifications? > It was not send to the PAM project (at least I never got something). >From what I understand how it works I would also not accept it, since >it would create a big security hole. > Yes, I agree that there must be nothing like security hole in auth-mechanism. What I don't understand is what kind of security hole you mean - if this is conditionally built ONLY when a kind of TESTING macro is defined, resulting in a 'libpamtest' library (to be not in colision with 'libpam' ...). Maybe other mechanisms preventing the use of such test library by root, or instead of system 'libpam' could be applyed? > It would be really better to work only with a copy of libpam configured > with different paths. > > > Thorsten Yes, I use it right now. But from the point of view of (maybe not very experianced, but still) PAM module developer, I tkink that this solution is not so flexible to make the development of modules easy, confortable and testable. Even tests in 'xtest' seems to require cooperation with system PAM and thus root account (stuff like '/usr/sbin/groupadd tstpamaccess' in 'tst-pam_access2.sh' ...) - well build with custom paths may help, but what is the difference between build a 'libpam' with custom paths, and build a 'libpamtest' which is able to read paths from somewhere (I do not say that it must be from env variables) any time it is used (allowing to change a config directory for each test case?). Moreover, extra testing applications (like 'pamtester') could be build against 'libpamtest', symplifying the need of a custom build of such applications. And there is also a question of module unit-testing abilities ... So again, please believe me that I undestand your fear and I completely agree with you about high security which must be ensured by PAM. But instead of rejecting any attempts to make the testing of pam modules "pleasant" for 3rd party developpers (who often do it in their free times, maybe as well as you), let us discuss about the possibilities of how to make it. I can present my "high level" idea, how I would like to have a module test to be configurable, and that we can discuss the possibilities how to reach this state. If we decide on something siply writable and even simpler usable, I would be glad to write it and prove its usability for testing. Best regards, Dan _______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
