Hi, > > > One tiny thing -- I wouldn't neccesarily make it a environment > > > variable, make it an option instead. Env vars are too hard to keep > > > track of. > > > > Matt > > Huh, libraries do not have options, it is executables who get them. No. It is perfectly legal to specify options to PAM modules, and the module get's the argc / argv in the pam_sm_* functions. > Do you Matt mean each program usign libpam has to be modified to know an > extra option? :-) No. Try looking in a module's source. The prototype for for example pam_sm_authenticate : PAM_EXTERN int pam_sm_authenticate (pam_handle_t * pamh, int flags, int argc, const char ** argv) The argc / argv contain options given in the /etc/pam.d/* files. > > config-file=..... will do I think :) > > Where would you put that spell Igmar? Into a file? :) Into an option. Try actually looking in a module's source before saying things that aren't correct. > - I want to use existing pam-aware programs without modification The mods are done in PAM, programs have no business in knowing with PAM does beneeth. > - I want to control pam behaviour (like using my own set of modules) > when I protect my things with these programs > (as well as program run by root obey root's instructions) > but I cannot rely on the existence of a file in any "well known" > compiled-in location, even a "well-known name in the homedir" would > *not* (!) work in the long run Why not ?? The .bash_profile in a user's homedir has been there for ages and you're telling me that won't work ?? I can name a dozen of programs that do similair behaviour. > [the same program that calls the same pam-service may have to be run > by the same user with different module- and rule- sets at different > times or even simultaneously ] You can't. Users can't control what PAM does. Services get called using a static set of arguments. > > Regards, > -- > Ivan Regards, Igmar _______________________________________________ Pam-list@redhat.com https://listman.redhat.com/mailman/listinfo/pam-list
