Bug 10317 - race condition in vipw?
Summary: race condition in vipw?
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: util-linux   
(Show other bugs)
Version: 6.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Erik Troan
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-03-23 18:59 UTC by ahosey
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-07 15:53:12 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 ahosey 2000-03-23 18:59:31 UTC
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 15:53:07 UTC
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.