ntsec patch #4: passwd and group

Corinna Vinschen vinschen@redhat.com
Mon Nov 11 05:56:00 GMT 2002

On Fri, Nov 08, 2002 at 12:10:13PM -0500, Pierre A. Humblet wrote:
> Corinna Vinschen wrote:
> > Isn't that functionality already given by cygsid::getfrompw() and
> > cygsid::getfromgr()?
> Those functions don't scan the passwd file, they take a specific
> pw entry as argument and return the sid. The new functions take a 
> sid as argument and return a pw entry (behave as e.g. getpwuid). 

Ah, I see.

> > Yeah, we should think a bit about this.  Is that actually a problem?
> > AFAICS, the LookupAccountSidA() calls are only asking the local box.
> But the localbox will contact the PDC if the sid isn't local. 
> We have tested that already. Some people, with badly configured 
> group files, will think it's a problem! In my opinion it should 
> be a motivation to fix the group file. At any rate it's an unusual
> case to be disconnected from the PDC and to have a bad group file.

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

> Can you elaborate? Why is it a problem to store them in the 
> cygheap? 
> I saw Chris' comments about slowing things down. That makes 
> sense for programs that never stat or create a file with uid 
> and gid different from the current user.
> 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.

> > The passwd_lock and group_locks.  Look into the other functions, e.g.:
> > 
> >   getgrnam32 (const char *name)
> >   {
> >     if (group_state  <= initializing)
> >         read_etc_group ();
> 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.


More information about the Cygwin-developers mailing list