Prawdopodobnie byk w pam
Adam Osuchowski
adwol w polsl.gliwice.pl
Wto, 11 Mar 2003, 01:23:04 CET
Tomasz Kłoczko wrote:
> [root w test1 interfaces]# grep .pwd.lock out
> open("/etc/.pwd.lock", O_WRONLY|O_CREAT, 0600) = 5
> open("/etc/.pwd.lock", O_WRONLY|O_CREAT, 0600) = 8
>
> Czyli nie ma wogóle unlink() :>
> Dlaczego przypuszczam, ze to błąd w PAM ? Ano dlatego że jak w
> /etc/pam.d/passwd wstawiłem testowo:
>
> auth required /lib/security/pam_permit.so
> account required /lib/security/pam_permit.so
> password required /lib/security/pam_permit.so
>
> to /etc/.pwd.lock wogóle nie był dotykany. Sprawdziłem i blokowanie jest
> wykonywane w pam_unix. Na sparc mam wyjątkowo paskudne objawy tego. Wogóle
> nie można zmienić hasła z _użytkownika_ bo z root-a jakoś to przechodzi :>
> (nie mam jeszcze pojęcia dlaczego tylko na sparc ?).
unilnk() nie jest wolany bo configure nie ustawia stalej NEED_LCKPWDF, ktora
wymusza uzywanie pamowej wersji funkcji ulckpwdf(), ktora to z kolei wola
unlink()'a. Wersja glibc'owa tej funkcji natomiast nie kasuje pliku
.pwd.lock.
Chyba nalezy wymusic w configurze --enable-included-lckpwdf.
BTW, wydaje mi sie, ze kasowanie .pwd.lock nie jest potrzebne, bo pam_unix
blokuje to za pomoca flock/fcntl, wiec usuwanie nie zmienia postaci rzeczy.
--
## Adam Osuchowski adwol w polsl.gliwice.pl, adwol w silesia.linux.org.pl
## Silesian University of Technology, Computer Centre Gliwice, Poland
Więcej informacji o liście dyskusyjnej pld-devel-pl