pam_unix źle działa na Linuksie 2.6

[Jakub Bogusz]

vlock mnie nie chciał wpuścić, okazało się, że pam_unix ma taką
właściwość, jeśli hasło jest sprawdzane z uid>0.

A konkretnie przed wywołaniem /sbin/unix_chkpwd jest taki kawałek:

#v+
    if (off(UNIX_NOREAP, ctrl)) {
        /*
         * This code arranges that the demise of the child does not cause
         * the application to receive a signal it is not expecting - which
         * may kill the application or worse.
         *
         * The "noreap" module argument is provided so that the admin can
         * override this behavior.
         */
        sighandler = signal(SIGCHLD, SIG_IGN);
    }
#v-

A potem jest pobierany kod powrotu przez waitpid(child, &retval, 0).

No i to działało na 2.2 i 2.4, nie działa na 2.6. Nie wiem, czy to
zamierzone, czy nie (SIGCHLD się ustawia na SIG_IGN żeby nie trzeba było
robić wait() - co jest zresztą nieprzenośne - ale z takim użyciem się
nie spotkałem w innych programach).
Na 2.6 vlock nie z roota działa dopiero po dodaniu "noreap" do
/etc/pam.d/vlock.

Prosty testcase:

#v+
#include <signal.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>

int main()
{ int child, retval, x;

  signal(SIGCHLD, SIG_IGN);
  if((child = fork()) == 0) {
    execl("/bin/ls", NULL);
  } else {
    x = waitpid(child, &retval, 0);
  }
  printf("retval=%d, pid=%d\n", retval, x);
  return 0;
}
#v-

Na 2.4 to zwraca na przykład:
retval=0, pid=3220

Na 2.6 pid=-1, a retval pozostaje jakimś śmieciem ze stosu.


Czy rozwiązanie użyte w pam_unix jest poprawne?
Tzn. co powinno być poprawione - pam czy jądro?


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/