Bad configure test for getpwent() ?

Bad configure test for getpwent() ?

[Bart Schaefer]

No patch because I'm not sure it's wrong, but there's this test:

--- 8< --- cut ---
dnl -----------
dnl test for faked getpwnam() entry, ie a single entry returned for any username
dnl for instance, BeOS R4.51 is not multiuser yet, and fakes getpwnam()
dnl test by looking up two usernames that shouldn't succeed, and compare entry
dnl -----------
if test $ac_cv_func_getpwnam=yes; then
    AC_CACHE_CHECK(if getpwnam() is faked,
    zsh_cv_sys_getpwnam_faked,
    [AC_TRY_RUN([
#include <pwd.h>
main() {
    struct passwd *pw1, *pw2;
    char buf[1024];
    sprintf(buf, "%d:%d", getpid(), rand());
    pw1=getpwnam(buf);
    sprintf(buf, "%d:%d", rand(), getpid());
    pw2=getpwnam(buf);
    exit(pw1!=0 && pw2!=0 && !strcmp(pw1->pw_name, pw2->pw_name));
}
],
      zsh_cv_sys_getpwnam_faked=no,
      zsh_cv_sys_getpwnam_faked=yes,
      zsh_cv_sys_getpwnam_faked=no)])
    if test $zsh_cv_sys_getpwnam_faked = yes; then
      AC_DEFINE(GETPWNAM_FAKED)
    fi
fi
--- 8< --- cut ---

I don't think getpwent() is required to return a unique pointer each time;
that is, I think it's allowed to re-use an internal static buffer for each
entry that it returns.  That would mean that this test always succeeds ...

I think the only right way is to test the first pointer for nonzero, copy
the entry into a local struct passwd, then call getpwent() again and do
the comparison.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Bad configure test for getpwent() ?

[Clint Adams]

>     pw1=getpwnam(buf);
>     sprintf(buf, "%d:%d", rand(), getpid());
>     pw2=getpwnam(buf);
>     exit(pw1!=0 && pw2!=0 && !strcmp(pw1->pw_name, pw2->pw_name));

It's not comparing the pointers; it's comparing the names.

> I don't think getpwent() is required to return a unique pointer each time;
> that is, I think it's allowed to re-use an internal static buffer for each
> entry that it returns.  That would mean that this test always succeeds ...

Re: Bad configure test for getpwent() ?

[Geoff Wing]

Clint Adams <schizo@debian.org> typed:
:>     pw1=getpwnam(buf);
:>     sprintf(buf, "%d:%d", rand(), getpid());
:>     pw2=getpwnam(buf);
:>     exit(pw1!=0 && pw2!=0 && !strcmp(pw1->pw_name, pw2->pw_name));
:
:It's not comparing the pointers; it's comparing the names.
:
:> I don't think getpwent() is required to return a unique pointer each time;
:> that is, I think it's allowed to re-use an internal static buffer for each
:> entry that it returns.  That would mean that this test always succeeds ...

My man page says:
  BUGS
    The functions getpwent(), getpwnam(), and getpwuid(), leave their results
    in an internal static object and return a pointer to that object. Subse-
    quent calls to any of these functions will modify the same object.

On my system then, pw2 will be the same as pw1.

Bart typed:
:I think the only right way is to test the first pointer for nonzero, copy
:the entry into a local struct passwd, then call getpwent() again and do
:the comparison.

I'd say this is correct.

Regards,
-- 
Geoff Wing : <gcw@pobox.com>     Work URL: http://www.primenet.com.au/
Rxvt Stuff : <gcw@rxvt.org>      Ego URL : http://pobox.com/~gcw/
Zsh Stuff  : <gcw@zsh.org>       Phone   : (Australia) 0413 431 874

Re: Bad configure test for getpwent() ?

[Clint Adams]

> :It's not comparing the pointers; it's comparing the names.

Sorry, I wasn't thinking.

Re: Bad configure test for getpwent() ?

[Bart Schaefer]

On Nov 3,  1:39pm, Clint Adams wrote:
> Subject: Re: Bad configure test for getpwent() ?
> >     pw1=getpwnam(buf);
> >     sprintf(buf, "%d:%d", rand(), getpid());
> >     pw2=getpwnam(buf);
> >     exit(pw1!=0 && pw2!=0 && !strcmp(pw1->pw_name, pw2->pw_name));
> 
> It's not comparing the pointers; it's comparing the names.

If pw1 == pw2, always, then strcmp(pw1->pw_name, pw2->pw_name) == 0, always.

> > I don't think getpwent() is required to return a unique pointer each time;
> > that is, I think it's allowed to re-use an internal static buffer for each
> > entry that it returns.  That would mean that this test always succeeds ...
>-- End of excerpt from Clint Adams