Date: Wed, 13 Mar 2002 03:52:40 -0800 From: "Crist J. Clark" <crist.clark@attbi.com> To: Dima Dorfman <dima@trit.org> Cc: billf@FreeBSD.ORG, irys@irc.pl, freebsd-bugs@FreeBSD.ORG Subject: Re: i386/35816: no one can change password, because "passwd DB is locked" Message-ID: <20020313035240.S29705@blossom.cjclark.org> In-Reply-To: <20020313112322.C0F1B3E31@bazooka.trit.org>; from dima@trit.org on Wed, Mar 13, 2002 at 11:23:17AM %2B0000 References: <20020313025449.R29705@blossom.cjclark.org> <20020313112322.C0F1B3E31@bazooka.trit.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 13, 2002 at 11:23:17AM +0000, Dima Dorfman wrote:
> "Crist J. Clark" <cjc@FreeBSD.ORG> wrote:
> > On Tue, Mar 12, 2002 at 03:43:52AM -0800, billf@FreeBSD.ORG wrote:
> > > Synopsis: no one can change password, because "passwd DB is locked"
> > >
> > > 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.
> >
> > This does look like a bug to me. I don't understand why chpass(1)
> > needs to hold a lock on the database while the user is editing his
> > entry. It seems like once the user is done editing, _then_ the
> > master.passwd can be locked, the user's modifications checked, and
> > then added if they are OK. Why would it need to be locked during the
> > editing process? I don't see a good reason looking at the code.
>
> 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.
Let me clarify on how I would expect this to work,
1) chpass reads info from master.passwd.
2) chpass creates the temporary file with the data.
3) chpass allows the user to edit whatever information is allowed.
4) chpass re-reads and locks the master.passwd (note that user
interaction has finished).
5) chpass checks that the changes are sane (that the user still
exists, that fields that the user cannot change are not reverted,
etc.).
6) chpass merges the changes to this one user into the newly locked
master.passwd.
6) chpass makes the new master.passwd and db.
7) chpass unlocks master.passwd.
There is the possibility that one, or more than one, user could be
changing the chpass(1) at once. What will happen is the last one to
finish his edits in chpass(1) wins. I really don't see too much of a
problem with this. How much different is it than users running
chpass(1) consecutively, but having to wait until the other is
finished? It just means you always have to wait to see what changes
the other user made before you get to make yours. My best guess is
that the current behavior is just what was easiest to code at the
time. If you lock the master.passwd file at the begining, there are
some checks you can skip later on.
It seems to me the price of maybe creating slight disorientation in
rare circumstances is far outweighed by the current behavior which
allows any user on the system to create a fairly effective DoS
requiring someone with super-user access to manually intervene.
--
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?20020313035240.S29705>