Date: Wed, 13 Mar 2002 15:00:07 -0800 (PST) From: "Crist J. Clark" <crist.clark@attbi.com> To: freebsd-bugs@FreeBSD.org Subject: Re: i386/35816: no one can change password, because "passwd DB is locked" Message-ID: <200203132300.g2DN07R53127@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: "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
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?200203132300.g2DN07R53127>