Races in group/passwd code (was Re: etc_changed, passwd & group)
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?
>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.
>> 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