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