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: Tue, 12 Nov 2002 14:40:38 +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: <20021112144038.F10395@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> <20021111145612 DOT T10395 AT cygbert DOT vinschen DOT de> <3DCFC6BB DOT 570DF472 AT ieee DOT org> <20021111174720 DOT X10395 AT cygbert DOT vinschen DOT de> <3DCFE314 DOT 3B5B45AB AT ieee DOT org> <20021111183423 DOT A10395 AT cygbert DOT vinschen DOT de> <3DCFF8AE DOT 66CBD751 AT ieee DOT org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3DCFF8AE.66CBD751@ieee.org>
User-Agent: Mutt/1.3.22.1i

On Mon, Nov 11, 2002 at 01:36:30PM -0500, Pierre A. Humblet wrote:
> Corinna Vinschen wrote:
> > But 2 is not an issue.  The appl. called getpwuid once and then the
> > static buffer contains data.  That's it. 
> 
> At this point the application may do an open (), stat () or setuid (), 
> intending to use the static buffer immediately after those calls
> (a likely scenario with setuid () ?). However those calls may invalidate 
> the pointers in the buffer.

I'm not sure if we're talking about the same static buffer.  What I'm
trying to say is, that (for instance) getpwuid() must provide it's
own static buffer to not collide with the changing passwd list:

So roughly it should work like this:

  struct passwd *getpwuid()
  {
    static struct passwd pw, *pwlist_ptr;
    static char buf[MAX_USEFUL_SIZE];

    if (pwlist_ptr = search_for (uid, 0))
      {
        copy_list_member_to_pw_buf (pwlist_ptr, &pw, buf);
	return &pw;
      }
    return NULL;
  }

The copy_list_member_to_pw_buf() function must apparently set the
correct pointer values in the pw struct to something pointing into
the local buf so I don't quite understand what you're up to.

Anyway, since the external getpwXXX and getgrXXX functions are
not independent from their siblings, they even may share the same
global static area.  SUSv3 says:

"The return value may point to a static area which is overwritten
 by a subsequent call to getpwent(), getpwnam(), or getpwuid()."

> I am not saying that this is a problem that needs immediate fixing,
> only that it is an area of non-compliance. We may want to pay attention
> to it when we revisit pw/gr to address the thread issues. 

To add another point, SUSv3 says:

"The getpwuid() function need not be reentrant. A function that is
 not required to be reentrant is not required to be thread-safe."

IMHO that means, we don't even have to care for the mutex thingy.
It's ok as it is.  Except for only the getpwuid_r() call.

> I thought I had sent them in November, after you came back 
> (after you sent the sshd update), but then you probably got a lot 
> to do those days. Nothing has changed on my side, could you pick them 
> up on the list? Thanks.

I'm sorry, I wasn't resubscribed until the 8th of November.  I'm
currently looking into #1.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin AT cygwin DOT com
Red Hat, Inc.