Andrew Morgan wrote: > > "Michael Ju. Tokarev" wrote: > > 4.a. why current pam_unix uses "strange" method of "storing" password > > afetr a user prompt? Here is a simplified code: > > > > pam_converse(..., &resp, ...); > > pass = strdup(resp[0].resp); > > pam_drop_reply(resp); > > I think this was intended (one late night) as a paranoia thing. The > intention was to explicitly break the link between any dangling pointer > reference in some state that the application (conversation function) > might have, to the current location of the password. The reasoning being > that it is easier to audit a module's use of a password if you know > there are no other references to the memory it is stored in (outside the > module and by extension the libc it uses for something like strdup()). > > That was the intention at least, hindsight and years later, it looks a > little optimistic. The funny thing about all that stuff together with pam_overwrite() et al in many places (and in Steve's (non-public) patches for pwdb) is that anyway password(s) are in pam items during all the time between pam_start (after auth, when pam_set_item(AUTHTOK) called) and pam_end. Thus, password is accessible, and that "protection" (declaring PAM_[OLD]AUTHTOK in the file that should not be included by app) is just like a joke. Numbers for that #defines are "standard", so that file is not needed. Moreover, that authtok comes from application itself as an answer to conversation function, so app have it "in the first place". Doh! This is not to say that all that care with pam_overwtite etc is not necessary -- the less places that "knows" the password will be, the less chances to use it. Maybe in some future time authtoks will be stored in some other safe place (like signing log records in modern syslog-ng -- who taked care of that 10 years ago?!) that will be unaccessible to app... :) But I see the point here (around my original question), and I already realized that myself. Thanks for info anyway. Regards, Michael.
