Mail Archives: cygwin-developers/2002/11/11/10:03:19
Corinna Vinschen wrote:
>
> I agree. We're just trying to workaround problems with bad setups.
> The vision is that after running setup, everything works perfectly.
> But I don't see that the LookupAccountSidA() call makes it actually
> better.
Simply that a user typing "id" or "ls -l" will see the correct group
name. No big deal either way.
> > However when Chris was doing the test this caching mechanism
> > wasn't present yet, stating or creating any file would force
> > a passwd/group reread. So it's more surprising.
>
> AFAIR, Chris was surprised, too. I don't know more details, though.
I looked at how the gcc chain behaves on my machine and only one
program was reading passwd (that depends on file ownership).
So I have abandoned the idea of using the cygheap and I have simply
fixed the memory leak in grp.cc.
> > Right, that's what I meant by "I see some mutual exclusion stuff".
> > Assuming it works, after the thread has gone through the test and
> > is happily scanning the internal passwd, a user could touch passwd
> > and another thread could come along and free that internal structure.
>
> Hmmm. I understand. Yes, that's actually potentially harmful.
> So we have to encapsulate the whole call into a mutex bracket,
> unfortunately... Oh, and all returned pointer would have to
> point to a copied datatstructure instead of pointing into
> the passwd or group structure.
Exactly, we need one of these "one writer or many readers" mutexes.
Let's break the discussion between the Cygwin internal use of
passwd/grp and the external API.
For the internal use, one of the reasons why I created getpwsid and
getgrsid is that it will be easy to put a mutex around the scan loops
(we don't want to have a mutex inside those loops; having these
functions also eliminates the
"if (group_state <= initializing) read_etc_group (); ",
inside the loop, which looks up etc_changed etc...)
There are still a couple of places where internal_getgrent () is
called and they will have to be cleaned up some way.
For the external API, a mutex isn't enough, we will have to copy the
strings that are in the internal buffer. That will work for the _r series
of pw/gr calls, but not for the calls returning static storage.
That's why I was asking if you knew applications that NEED to reread
passwd/group as soon as it is changed. Programs such as sshd, inetd,
exim, etc all fork or exec childs that read the passwd file, the main
process doesn't care.
Cygwin seems to be working fine without that anyway, although
I am not even sure that it prevents simultaneous writes!
Pierre
P.S.: did you have a chance to look at the first three patches?
- Raw text -