Bug 27004 - locking on /etc/passwd 'interesting' in adduser
Summary: locking on /etc/passwd 'interesting' in adduser
Status: CLOSED DUPLICATE of bug 126709
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: shadow-utils   
(Show other bugs)
Version: 6.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Eido Inoue
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-02-11 02:41 UTC by Andrew Bartlett
Modified: 2007-04-18 16:31 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 18:47:54 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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.

Note You need to log in before you can comment on or make changes to this bug.