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

[Christopher Faylor]

On Tue, Jan 21, 2003 at 11:47:35AM -0500, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>
>> You'd need a per-thread buffer to accomplish that.  I assume that
>> is what you had in mind.
>
>If you look at them, most internal_get{pw,gr} calls from outside
>of passwd.cc and grp.cc only want the {u,g}id, the sid or the name,
>but never the other fields. 

getpwuid_r32

>I wanted to avoid copying the entire line, at least in the first
>two cases.

Not copying is a good goal.  I guess there is no reason why the lock
couldn't be exported to everyone.

Except for the problem with locks and signals, this isn't a big issue,
as you know.  However, since I was in the process of cleaning some of
this up, I thought I'd try to at least close the window a little.

>> I wonder how many inexplicable "cygwin hangs" issues this is
>> responsible for.
>
>Problems only happen when updating passwd/group while a program
>is running. At least in case of the recent BSOD, users were
>very good correlating the two events.

There is a potential for essentially causing a deadlock due to
the fact that pthread locks are not recognized by the signal code.
If a signal handler is called in the middle of a passwd or group
read, then there is a potential for a hang.  It's easy enough to
fix by using mutos and I will do that in the next couple of days.

cgf