Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Mon, 11 Nov 2002 14:56:12 +0100
From: Corinna Vinschen <vinschen AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: ntsec patch #4: passwd and group
Message-ID: <20021111145612.T10395@cygbert.vinschen.de>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <3DCBD52C DOT A1F794FD AT ieee DOT org> <20021108171918 DOT P21920 AT cygbert DOT vinschen DOT de> <3DCBEFF5 DOT 850B999E AT ieee DOT org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3DCBEFF5.850B999E@ieee.org>
User-Agent: Mutt/1.3.22.1i

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