From nobody@FreeBSD.org  Tue Mar 12 03:01:00 2002
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 8460037B436
	for <freebsd-gnats-submit@FreeBSD.org>; 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 <irys@irc.pl>
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 <keramida@freebsd.org>
To: Dima Dorfman <dima@trit.org>
Cc: "Crist J. Clark" <cjc@freebsd.org>, 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" <crist.clark@attbi.com>
To: Giorgos Keramidas <keramida@freebsd.org>
Cc: Dima Dorfman <dima@trit.org>, 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 <keramida@freebsd.org>
To: "Crist J. Clark" <crist.clark@attbi.com>
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" <crist.clark@attbi.com>
To: Giorgos Keramidas <keramida@freebsd.org>
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:
