pam_unix źle działa na Linuksie 2.6

Jakub Bogusz qboosh w pld.org.pl
Pon, 4 Sie 2003, 13:20:12 CEST


On Wed, Jul 30, 2003 at 10:02:26PM +0200, Jakub Bogusz wrote:
> 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.
[...]

Już wiem - z manuala do wait(2) oraz SUSv2 wynika, że...

> Czy rozwiązanie użyte w pam_unix jest poprawne?

nie.
Linux do 2.4.x włącznie był w tym miejscu niezgodny ze specyfikacją.
W 2.6 to poprawili.

Odpowiedni fragment SUSv2:
http://www.opengroup.org/onlinepubs/007908799/xsh/wait.html

If the calling process has SA_NOCLDWAIT set or has SIGCHLD set to
SIG_IGN, and the process has no unwaited for children that were
transformed into zombie processes, the calling thread will block until
all of the children of the process containing the calling thread
terminate, and wait() and waitpid() will fail and set errno to [ECHILD].

> Tzn. co powinno być poprawione - pam czy jądro?

Czyli pam_unix do poprawki.
Tylko pytanie jak rozwiązać problem opisany w komentarzu - ustawiając
własną, pustą procedurę obsługi SIGCHLD w tym miejscu?


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



Więcej informacji o liście dyskusyjnej pld-devel-pl