Date: Thu, 14 Mar 2002 15:40:02 -0800 (PST) From: Giorgos Keramidas <keramida@freebsd.org> To: freebsd-bugs@FreeBSD.org Subject: Re: i386/35816: no one can change password, because "passwd DB is locked" Message-ID: <200203142340.g2ENe2F46399@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/35816; it has been noted by GNATS.
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/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203142340.g2ENe2F46399>