Date: Thu, 14 Mar 2002 01:55:37 +0100 From: "Simon 'corecode' Schubert" <corecode@corecode.ath.cx> To: "Crist J. Clark" <crist.clark@attbi.com> Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: i386/35816: no one can change password, because "passwd DB is locked" Message-ID: <20020314015537.62a8db2e.corecode@corecode.ath.cx> In-Reply-To: <200203132300.g2DN07R53127@freefall.freebsd.org> References: <200203132300.g2DN07R53127@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=.u?24y,1C?WJrb+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 13 Mar 2002 15:00:07 -0800 (PST) "Crist J. Clark" <crist.clark@attbi.com> wrote: > 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. how about an additional check that assures that the settings for the user didn't change between first reading master.passwd and reading master.passwd for merging the changes; if these settings don't match, prompt the user again to redo the changes with the new settings (like cvs does for merging). cheerz corecode -- /"\ http://corecode.ath.cx/ \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News --=.u?24y,1C?WJrb+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE8j/UMr5S+dk6z85oRAnmrAKCjFOSHB255zWr8EzDrX88qp2BJ8QCgzkuR Zrucral61y1SX5L7UeYXTm8= =tOYH -----END PGP SIGNATURE----- --=.u?24y,1C?WJrb+-- 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?20020314015537.62a8db2e.corecode>