Re: [PATCH] Re: pthread -- Corinna?

[Corinna Vinschen <cygwin-patches at cygwin dot com>]

On Tue, Apr 17, 2001 at 12:51:37AM -0400, Christopher Faylor wrote:
> On Tue, Apr 17, 2001 at 02:03:19PM +1000, Robert Collins wrote:
> >I've remembered my key thought:
> > [...]
> You probably know this, but, [...]
> >I think we should [...]
> Ah right. [...]
> >> >A true semaphore could [...]
> >> Still not convinced.
> >> [...]
> >Nope, [...]
> Yes.  [...]
> >Get_id_from_sid should know [...]
> >> Maybe [...]
> >Ahh, [...]
> passwd_state <= initializing
>  
> >> Hmm, again.  [...]
> >Why don't we [...]
> I won't disagree [...]
> Index: security.cc
> ===================================================================
> [...]

Ok, I'm in the subject so I think I should say something here, too.
You both have told so much, back and forth, that I'm not quite sure
how to tie in. Anyway.

Robert is right in that we have two different problems. In my own
words:

- n>1 threads could try to call read_etc_passwd() nearly
  simultaneously. This is a problem which could be handled by a
  mutex or a critical section handler, perhaps.

- get_id_from_sid is called from open if and only if ntsec is ON.
  That's a problem which is thread internal. Each single thread
  would have the same problem and it's related to the usage of
  `fopen' in read_etc_passwd() and read_etc_group(). `passwd_sem'
  and `group_sem' are just gatekeeper to avoid the recursion.

  Obviously, the usage of these variables isn't thread safe.
  The joke here is that the kernel (urgh, Cygwin itself) doesn't
  need ntsec. It should always be able to open /etc/passwd and
  /etc/group.
  
  So, the better way is probably to drop both ..._sem variables and
  just switch off allow_ntsec in read_etc_...() before opening a
  file and restoring the setting afterwards.

  If that's done inside of the above mentioned mutex or critical section
  protected area in read_etc_...(), it's protected against changings by
  simultaneous threads, too.

Corinna