Races in group/passwd code (was Re: etc_changed, passwd & group)

[Pierre A. Humblet]

Christopher Faylor wrote:
> 
> After consolidating all of the lock code into a "refresh" method,
> I realized that there are some pretty big races in the group/passwd
> code.  You can't just protect the reading of the buffers against
> multiple access, you have to protect all operations which manipulate
> the passwd/group buffers since they could be changed out from under
> you otherwise.

That's absolutely right. The current logic protects only against 
concurrent writes (which are very unlikely due to the 
WaitForSingleObject), but not against conflicts between writers
and readers. That was discussed before. The lock must be set
before calling isinitializing. It can either be a simple lock, 
or a sophisticated one writer/many readers. 
Now there is a new twist: interaction between the passwd and the
group accesses.

This has been there forever, I would not delay the release of 1.3.19

By the way, I wrote the internal_get{pw,gr} routines having in mind
that they could be extended to handle those multiple access issues,
avoiding to have to set and release locks in routines outside of
passwd.cc and group.cc (with a few exceptions).
 
Pierre