From nobody@FreeBSD.org Tue Mar 12 03:01:00 2002 Return-Path: Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8460037B436 for ; Tue, 12 Mar 2002 03:00:58 -0800 (PST) Received: (from nobody@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g2CB0wv92939; Tue, 12 Mar 2002 03:00:58 -0800 (PST) (envelope-from nobody) Message-Id: <200203121100.g2CB0wv92939@freefall.freebsd.org> Date: Tue, 12 Mar 2002 03:00:58 -0800 (PST) From: Slawomir Parysek To: freebsd-gnats-submit@FreeBSD.org Subject: no one can change password, because "passwd DB is locked" X-Send-Pr-Version: www-1.0 >Number: 35816 >Category: i386 >Synopsis: no one can change password, because "passwd DB is locked" >Confidential: no >Severity: serious >Priority: medium >Responsible: cjc >State: closed >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Mar 12 03:10:01 PST 2002 >Closed-Date: Sun Mar 24 02:55:44 PST 2002 >Last-Modified: Sun Mar 24 02:55:44 PST 2002 >Originator: Slawomir Parysek >Release: 4.5-RELEASE >Organization: ArgNet >Environment: FreeBSD my.host.name.com.pl 4.5-RELEASE FreeBSD 4.5-RELEASE #0: Mon Jan 28 14:31:56 GMT 2002 murray@builder.freebsdmall.com:/usr/src/sys/compile/GENERIC i386 >Description: When one (malicious) user edit his own passwd database (via $ chpass command), no one can change password, because "passwd DB is locked". Also root cant't change any information in passwd database, eg add/delete It is very importand problem especialy on systems whih acts as shell box (TM.). >How-To-Repeat: how to repeat, huh, thats simple: log in into accont and leave an running "chpass" command on screen and log out, huh noone can change his/her passd and/or any other info by editing /etc/passwd* etc >Fix: how to fix it? hmm... block acces to command chpass for all suspicous users ;-P >Release-Note: >Audit-Trail: 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. http://www.FreeBSD.org/cgi/query-pr.cgi?pr=35816 From: Giorgos Keramidas To: Dima Dorfman Cc: "Crist J. Clark" , bug-followup@freebsd.org Subject: Re: i386/35816: no one can change password, because "passwd DB is locked" Date: Wed, 13 Mar 2002 20:54:42 +0200 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? Giorgos Keramidas FreeBSD Documentation Project keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/ 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 From: Giorgos Keramidas To: "Crist J. Clark" Cc: bug-followup@freebsd.org Subject: Re: i386/35816: no one can change password, because "passwd DB is locked" Date: Thu, 14 Mar 2002 21:46:34 +0200 On 2002-03-13 15:00, Crist J. Clark wrote: > > - 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? > > 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. Still can be problematic, when two admins attempt to edit the information of the same user. I don't think that dropping locking from chpass is a nice idea, to make things 'easier for admins who can't use ps(1)' is a good idea. But this is of course, MHO. Giorgos Keramidas FreeBSD Documentation Project keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/ State-Changed-From-To: closed->analyzed State-Changed-By: cjc State-Changed-When: Fri Mar 15 03:04:07 PST 2002 State-Changed-Why: I think I have a pretty straightforward fix for this. Responsible-Changed-From-To: freebsd-bugs->cjc Responsible-Changed-By: cjc Responsible-Changed-When: Fri Mar 15 03:04:07 PST 2002 Responsible-Changed-Why: I think I have a pretty straightforward fix for this. http://www.freebsd.org/cgi/query-pr.cgi?pr=35816 From: "Crist J. Clark" To: Giorgos Keramidas Cc: bug-followup@freebsd.org Subject: Re: i386/35816: no one can change password, because "passwd DB is locked" Date: Sun, 17 Mar 2002 18:27:32 -0800 Committed the approach from NetBSD (OpenBSD is about the same). Will MFC to -STABLE in about a week. cjc 2002/03/17 18:22:53 PST Modified files: usr.bin/chpass chpass.c pw_copy.c pw_copy.h Log: It was possible for an unprivileged user to tie up the password information (no one else can vipw(8), chpass(1), or even passwd(1)), either on purpose or by accident, until an administrator manually intervened. Instead, do not lock the master.passwd file while a user is editing his information. But once we go to write the new information, check that the modified user's information has not changed in the password database since we started. Abort the changes if it has. Add a $FreeBSD$ to pw_copy.h. PR: i386/35816 Obtained from: NetBSD MFC after: 1 week Revision Changes Path 1.19 +29 -22 src/usr.bin/chpass/chpass.c 1.11 +34 -2 src/usr.bin/chpass/pw_copy.c 1.2 +2 -2 src/usr.bin/chpass/pw_copy.h -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org State-Changed-From-To: analyzed->closed State-Changed-By: cjc State-Changed-When: Sun Mar 24 02:55:18 PST 2002 State-Changed-Why: MFCed to -STABLE. http://www.freebsd.org/cgi/query-pr.cgi?pr=35816 >Unformatted: