From owner-freebsd-bugs Wed Mar 13 15: 0:35 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 69E7837B404 for ; Wed, 13 Mar 2002 15:00:08 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g2DN07R53127; Wed, 13 Mar 2002 15:00:07 -0800 (PST) (envelope-from gnats) Date: Wed, 13 Mar 2002 15:00:07 -0800 (PST) Message-Id: <200203132300.g2DN07R53127@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Crist J. Clark" Subject: Re: i386/35816: no one can change password, because "passwd DB is locked" Reply-To: "Crist J. Clark" 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 The following reply was made to PR i386/35816; it has been noted by GNATS. From: "Crist J. Clark" To: Giorgos Keramidas Cc: Dima Dorfman , bug-followup@freebsd.org Subject: Re: i386/35816: no one can change password, because "passwd DB is locked" Date: Wed, 13 Mar 2002 14:57:55 -0800 On Wed, Mar 13, 2002 at 08:54:42PM +0200, Giorgos Keramidas wrote: > On 2002-03-13 11:23, Dima Dorfman wrote: > > 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. > > > > The above is intended as food for thought, not a flat-out rejection of > > your idea; it isn't clear whether this should be allowed to happen, or > > what we should do if it does. > > Nice food for thought too. Imagine of the following scenario, on a machine > where two humans have root access: > > - User A runs 'chpass foo'. > - Before user A finishes, user B runs 'chpass foo' too. > - User A deletes account of user C. > - User B adds account of user D. > - User A commits changes. > - User B commits changes. > > Is the account of C still erased? Well, chpass(1) isn't really the right tool for deleting a user, but I think the answer to the spirit of your question would be, "Yes." Again, what I see happening is, 1) chpass(1) reads master.passwd to get info on user "C." 2) User A does whatever operations he pleases on user "C." 3) chpass(1) locks, and _re-reads_ master.passwd. It enters user "C"'s new info into master.passwd, does the ususal sanity checks, and then writes the new master.passwd, and releases the lock. That is, only information about user "C" is incorporated back into master.passwd in step (3). If another user is fiddling with user "D" during all of this, step three, the only step that actually changes the system files, doesn't touch user "D." So, for your question, "A" commits his changes, first, so "C" is gone. When "B" commits his changes, when master.passwd is re-read, "C" isn't there, but who cares, we're changing info on "D," so everything works fine. I think the issue here is the mindset that chpass(1) must take a complete copy of master.passwd, have the user perform some action on it, and then save the complete copy back. I don't see why it would work this way. Read info on our user being modified from master.passwd, have the user perform changes just on the data for this one user, _now_ lock and read master.passwd, incorporate the changes on that one user, and release the lock. -- 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