>> > > perhaps just change chfn to acquire the lock after it knows it has
>> > > stuff to change?
>> > 
>> > Sounds pretty good to me, unless there are some complications I can't
>> > see right now.
>> 
>> This doesn't work because somebody could make conflicting changes.
>
>Its actually probably okay in this instance. Remember that in general,
>only one user will be changing their one password line at a
>time. Others might be altering other lines of the password file, but
>thats okay. If someone else logged in as the same user makes the
>change, well, the user is screwed, but thats okay.

not even screwed necessarily.  chfn could indeed go ahead and change
the information in all situations (if it wanted to) *except* the one
where the other person editing the database was root, and (s)he was
removing your account.

>The Right Thing, IMHO, is for chfn to save information about the one
>line it is editing at the start and to check to make sure the line it
>is changing is unchanged after the user enters the new data and the
>lock has been made -- it should bail out if a change occurred to that
>line in the interim. As I noted, changes to other lines aren't
>important.

that would be about it.  and it doesn't even need to save the entire
line, just the gecos and shell info.  ideally, root would even be able
to change your username and chfn shouldn't care, since your uid would
still be the same.  :)

either way is better than allowing your users to arbitrarily lock the
password database "by mistake".

-- 
|-----< "CODE WARRIOR" >-----|
andrew@echonyc.com (TheMan)        * "ah!  i see you have the internet
codewarrior@daemon.org                               that goes *ping*!"
warfare@graffiti.com      * "information is power -- share the wealth."