This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: ntsec patch #4: passwd and group
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
better.
> 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.
Corinna