Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 27004

Summary: locking on /etc/passwd 'interesting' in adduser
Product: [Retired] Red Hat Linux Reporter: Andrew Bartlett <abartlet>
Component: shadow-utilsAssignee: Eido Inoue <havill>
Status: CLOSED DUPLICATE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 18:47:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andrew Bartlett 2001-02-11 02:41:08 UTC
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.)

Comment 1 Rik van Riel 2004-09-26 20:57:15 UTC
Yes this duplicate marking is backwards - but the other bug has the fix.

*** This bug has been marked as a duplicate of 126709 ***

Comment 2 Red Hat Bugzilla 2006-02-21 18:47:54 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.