I have been using adduser in a cgi-script (setuid root) and using it to
allow users to setup accounts based on inital passwords. This is in a
school setting, and whole classes are changing their passwords at once.
This brings the whole lockfile system into play - and it appears that is
occasionly breaks, leaving a collection of lockfiles in /etc.
Despite this, the entire system seemed to work - most users just resent
their request if it failed - but I decided to look into what the whole
The lockfiles in /etc were in the form pwd.%d.12345 (yes, the %d was
actualy in the lockfile name) and spwd.12345. (where 12345 varied and I
presume is the pid of the process aquiring the lock). I am supprised these
wern't cleaned up by adduser.
I've also looked into the source of various programs involved and I'm also
worried that PAM may not be checking the same locks as adduser, but it
*seems* to have worked. (and it passes pwck).
Is there any possibility of some consistant method for locking /etc/passwd
and /etc/shadow? We seem to have /etc/.pwd.lock, /etc/pwd.%d.12345 and
/etc/spwd.12345 and whatever vipw uses.
(A note on my system: Its a Pentium 166, and the CGI is compiled for each
request - its a perl script - and is run under mod_ssl, so the entire thing
runs under *very* heavy load when the entire class clicks OK at one. This
no doubt causes problems that wouldn't be seen under sane conditions.)
Yes this duplicate marking is backwards - but the other bug has the fix.
*** This bug has been marked as a duplicate of 126709 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.