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

Christopher Faylor cgf@redhat.com
Tue Jan 21 23:55:00 GMT 2003

On Tue, Jan 21, 2003 at 06:42:25PM -0500, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>> Btw, Pierre, can you explain the rationale behind the "check" parameter
>> that some of the internal_* functions take?  Why would you not want to
>> check for an up-to-date /etc/passwd or /etc/group?  
>Two reasons:
>1) "check" is only true when the internal functions are called from external
>functions. getpwuid and non-reentrant friends return pointers to the malloced
>copy. They have to remain valid at least until the next non-reentrant call,
>thus cannot be invalidated by refresh from internal lookup functions.
>This could be solved with per thread storage, but it's more expensive,
>maximum size becomes an issue, etc...
>2) internal lookups are used a lot to map uids from/to sids, so decreasing
>overhead for them looks like a good idea to make Cygwin faster.   

Ok, thanks.

>> If not for this, it
>> seems like we could get rid of the initialization check entirely and
>> just let fn_changed return true when fn[etc_ix] is uninitialized,
>> forcing an initial read/parse of the appropriate file.
>That's true for the "uninitialized" state (although it's a cheaper comparison)
>but not for the "initializing" state, at least with the current locking
>scheme. That condition is checked twice (before and after the mutex), whereas
>WaitForSingleEvent and fn_changed normally return false the second time 
>around even when true the first time.

Right, I was changing the locking to occur around the initialization check and
then wondered why we needed an initialization check at all.  I also used your
code/idea to get rid of the state entirely and just check for initialized.


More information about the Cygwin-patches mailing list