I suppose most of the time authentication childs actually exit? There's a lot of indirection in the source because it's a child that communicates with the greeter through another daemon. But AFAICS it expects PAM to free() the strings:
// callers of this function inside pam will expect to be able to call
// free() on the strings we give back. So alloc with malloc.
r->resp = read_string_full (malloc);
And hence there's no scrubbing: It expects PAM to do that. But if we look at the documentation:
The other arguments of a call to conv() concern the information
exchanged by module and application. That is to say, num_msg holds the
length of the array of pointers, msg. After a successful return, the
pointer resp points to an array of pam_response structures, holding the
application supplied text. The resp_retcode member of this struct is
unused and should be set to zero. It is the caller's responsibility to
release both, this array and the responses themselves, using free(3).
Note, *resp is a struct pam_response array and not an array of
pointers.
The number of responses is always equal to the num_msg conversation
function argument. This does require that the response array is
free(3)'d after every call to the conversation function. The index of
the responses corresponds directly to the prompt index in the
pam_message array.
Naively I'd say that the callback approach as implemented in lightdm is actually leaking the memory because it calloc()s the responses array in the callback and then passes the pointer to PAM to be done with it. Hence there's also nothing that'd go and scrub the memory afterwards.
I suppose most of the time authentication childs actually exit? There's a lot of indirection in the source because it's a child that communicates with the greeter through another daemon. But AFAICS it expects PAM to free() the strings:
// callers of this function inside pam will expect to be able to call
// free() on the strings we give back. So alloc with malloc.
r->resp = read_string_full (malloc);
And hence there's no scrubbing: It expects PAM to do that. But if we look at the documentation:
The other arguments of a call to conv() concern the information
exchanged by module and application. That is to say, num_msg holds the
length of the array of pointers, msg. After a successful return, the
pointer resp points to an array of pam_response structures, holding the
application supplied text. The resp_retcode member of this struct is
unused and should be set to zero. It is the caller's responsibility to
release both, this array and the responses themselves, using free(3).
Note, *resp is a struct pam_response array and not an array of
pointers.
The number of responses is always equal to the num_msg conversation
function argument. This does require that the response array is
free(3)'d after every call to the conversation function. The index of
the responses corresponds directly to the prompt index in the
pam_message array.
Naively I'd say that the callback approach as implemented in lightdm is actually leaking the memory because it calloc()s the responses array in the callback and then passes the pointer to PAM to be done with it. Hence there's also nothing that'd go and scrub the memory afterwards.