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 thing did: 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.