Date: Fri, 22 Aug 1997 10:26:20 -0700 (PDT) From: agonzalez@globalpc.net To: freebsd-gnats-submit@FreeBSD.ORG Subject: bin/4357: bug in adduser script causes duplicate UIDs Message-ID: <199708221726.KAA20794@hub.freebsd.org> Resent-Message-ID: <199708221730.KAA20888@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 4357 >Category: bin >Synopsis: bug in adduser script causes duplicate UIDs >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Aug 22 10:30:00 PDT 1997 >Last-Modified: >Originator: Adrian Gonzalez >Organization: Global PCNet >Release: 2.2.2-Release >Environment: FreeBSD nlaredo.globalpc.net 2.2.2-RELEASE FreeBSD 2.2.2-RELEASE #0: Thu Aug 7 13:56:15 CDT 1997 root@nlaredo.globalpc.net:/usr/src/sys/compile/LOCAL i386 >Description: While adding a user the other day, I noticed that if somebody else started another adduser script before I finished adding the current user, both would get assigned the same UID. Now, technically, this is not a bug, since the script asks you which UID you want to use, however, it would be quite hard to guess if somebody else is adding a user and what UID they're using. >How-To-Repeat: Run the adduser script and start answering the questions. Try adding a dumb user (test1) and get to the point where it asks for the UID. When you get there, start an adduser script from another session and add another dumb user (test2). When you get to the UID prompt, you will get the same UID for this user. If you go through and add the users, the script will happily add the two users with the same UID. >Fix: My suggestion would be to lock the password file from the beginning of the script and notify the user if it can't get a lock. That way there can only be one adduser script running at any given time. Looking at the script, however, this does not seem like a good idea. It uses a subroutine called 'append_file' that takes care of the locking while appending a line to a file. Personally, I'm going to do the pw file lock at the beginning, and make a modified append_file routine specifically for the password file (which will already be locked). Hopefully, the author will come up with a 'cleaner' solution later on :) >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708221726.KAA20794>