Bug 192138 - pw useradd and pw groupadd existence check races
Summary: pw useradd and pw groupadd existence check races
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 10.0-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-26 17:27 UTC by sheets
Modified: 2018-08-17 08:37 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sheets 2014-07-26 17:27:23 UTC
pw useradd has a race between checking if the username is already in use and updating the pw database:

getpwnam check <https://svnweb.freebsd.org/base/head/usr.sbin/pw/pw_user.c?revision=267970&view=markup#l602>

addpwent <https://svnweb.freebsd.org/base/head/usr.sbin/pw/pw_user.c?revision=267970&view=markup#l712> with useless return value check

pw_update without check or nonzero return inside of lock <https://svnweb.freebsd.org/base/head/usr.sbin/pw/pwupd.c?revision=267670&view=markup#l126>

pw groupadd has a race between checking if the groupname is already in use and updating the gr database:

getgrnam check <https://svnweb.freebsd.org/base/head/usr.sbin/pw/pw_group.c?revision=262864&view=markup#l102>

addgrent <https://svnweb.freebsd.org/base/head/usr.sbin/pw/pw_group.c?revision=262864&view=markup#l260> with useless return value check

gr_update without check or nonzero return inside of lock
<https://svnweb.freebsd.org/base/head/usr.sbin/pw/grupd.c?revision=243898&view=markup#l71>

This race is exhibited when multiple processes attempt to use the error return code of useradd/groupadd to indicate whether they have successfully created a unique user for themselves. If the race occurs, the uid/gid of the database entry may change out from under the first successful process as the second process finds an unused uid/gid and then updates the database using the same key (but the new uid/gid).

I don't believe this bug is a security vulnerability except in contexts where attackers may have control over user/group creation by applications assuming that the database locks ensure non-collision.

pw useradd/groupadd should either consistently let the operator overwrite existing groups/users or should consistently produce a name collision error

pw groupadd/useradd sometimes exits due to a name collision and sometimes overwrites existing groups/users
Comment 1 Mateusz Guzik freebsd_committer 2014-07-26 17:30:37 UTC
Not only that, pw is racy in general w.r.t other operations.

An acceptable way around this would be to have a lock (say, /etc/.pw.lock) which is taken at the beginning and released at the end. Preferably also supported by other tools playing with passwd (and other files).