From owner-freebsd-bugs Wed Mar 13 3:52:46 2002 Delivered-To: freebsd-bugs@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 12F2937B419; Wed, 13 Mar 2002 03:52:42 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020313115241.KZV1147.rwcrmhc52.attbi.com@blossom.cjclark.org>; Wed, 13 Mar 2002 11:52:41 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g2DBqes36918; Wed, 13 Mar 2002 03:52:40 -0800 (PST) (envelope-from cjc) Date: Wed, 13 Mar 2002 03:52:40 -0800 From: "Crist J. Clark" To: Dima Dorfman Cc: billf@FreeBSD.ORG, irys@irc.pl, freebsd-bugs@FreeBSD.ORG Subject: Re: i386/35816: no one can change password, because "passwd DB is locked" Message-ID: <20020313035240.S29705@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20020313025449.R29705@blossom.cjclark.org> <20020313112322.C0F1B3E31@bazooka.trit.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020313112322.C0F1B3E31@bazooka.trit.org>; from dima@trit.org on Wed, Mar 13, 2002 at 11:23:17AM +0000 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Mar 13, 2002 at 11:23:17AM +0000, Dima Dorfman wrote: > "Crist J. Clark" wrote: > > On Tue, Mar 12, 2002 at 03:43:52AM -0800, billf@FreeBSD.ORG wrote: > > > Synopsis: no one can change password, because "passwd DB is locked" > > > > > > State-Changed-From-To: open->closed > > > State-Changed-By: billf > > > State-Changed-When: Tue Mar 12 03:41:48 PST 2002 > > > State-Changed-Why: > > > this is not a bug. root can find the process that is holding the lock > > > on the password database and kill both it and the user holding it. > > > > This does look like a bug to me. I don't understand why chpass(1) > > needs to hold a lock on the database while the user is editing his > > entry. It seems like once the user is done editing, _then_ the > > master.passwd can be locked, the user's modifications checked, and > > then added if they are OK. Why would it need to be locked during the > > editing process? I don't see a good reason looking at the code. > > What happens if the data for that user changes between the time the > editor is started (with the old info filled in) and the time the user > is done editing? Assuming all the changes are valid, it would still > be technically okay to apply the new changes, but it might come as a > surprise to one or both of the parties involved. Let me clarify on how I would expect this to work, 1) chpass reads info from master.passwd. 2) chpass creates the temporary file with the data. 3) chpass allows the user to edit whatever information is allowed. 4) chpass re-reads and locks the master.passwd (note that user interaction has finished). 5) chpass checks that the changes are sane (that the user still exists, that fields that the user cannot change are not reverted, etc.). 6) chpass merges the changes to this one user into the newly locked master.passwd. 6) chpass makes the new master.passwd and db. 7) chpass unlocks master.passwd. There is the possibility that one, or more than one, user could be changing the chpass(1) at once. What will happen is the last one to finish his edits in chpass(1) wins. I really don't see too much of a problem with this. How much different is it than users running chpass(1) consecutively, but having to wait until the other is finished? It just means you always have to wait to see what changes the other user made before you get to make yours. My best guess is that the current behavior is just what was easiest to code at the time. If you lock the master.passwd file at the begining, there are some checks you can skip later on. It seems to me the price of maybe creating slight disorientation in rare circumstances is far outweighed by the current behavior which allows any user on the system to create a fairly effective DoS requiring someone with super-user access to manually intervene. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message