Bug 10317 - race condition in vipw?
race condition in vipw?
Product: Red Hat Linux
Classification: Retired
Component: util-linux (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Erik Troan
Depends On:
  Show dependency treegraph
Reported: 2000-03-23 13:59 EST by ahosey
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-07 10:53:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description ahosey 2000-03-23 13:59:31 EST
Inside the pw_lock() function in vipw, it is opening /etc/passwd before it
creates /etc/ptmp. This turns out to be a problem because imagine the

1. Another program is making changes to /etc/passwd using the /etc/ptmp
method (i.e. copy passwd to ptmp, alter it, rename it back). It has
completed its changes to /etc/ptmp and is ready to rename it back when its
timeslice expires.

2. vipw comes up and open()s an fd to /etc/passwd, then it's timeslice

3. The first program comes back up, rename()s /etc/ptmp to /etc/passwd, and
is done.

4. However, vipw stills holds a file descriptor on the _old_ data! Since
the first program's /etc/ptmp no longer exists, vipw copies the old data to
its new /etc/ptmp without ever knowing something is wrong.

I think the proper thing is for vipw to create it's /etc/ptmp first then
open() /etc/passwd.

This condition has apparently existed in vipw for years and still exists in
6.1 and 6.2 beta. If I am misunderstanding something here please let me
know. Thanks for your time.
Comment 1 Erik Troan 2001-02-07 10:53:07 EST
You're right, and this will be fixed in util-linux-2.10s-2 in rawhide. The patch
has been forwarded to, and accepted by, the util-linux maintainer.

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