Debian Bug report logs - #504787
manpages-dev: getpwnam_r does not return an error for non-existent user

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Andreas Henriksson <andreas@fatal.se>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: manpages-dev: getpwnam_r does not return an error for non-existent user

Date: Fri, 07 Nov 2008 09:45:18 +0100

Package: manpages-dev
Version: 3.07-1
Severity: minor

Hello!

This one just bit me and even though it might be considered a bug in glibc,
it would still be nice to have the problem documented.

It would be very nice if you could update the manpage with the fact that
getpwnam_r sometimes returns 0 even on failures and the return code alone
should not be trusted!


ie. getpwnam_r on non-existent users returns 0 and the the result pointer
pwbufp is NULL, so you need to check both the return code *and* make sure
the result is not a NULL-pointer.

See https://bugzilla.novell.com/show_bug.cgi?id=305053


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (300, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages manpages-dev depends on:
ii  manpages                      3.07-1     Manual pages about using a GNU/Lin

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  man-db [man-browser]          2.5.2-3    on-line manual pager

-- no debconf information

Message #10 received at 504787@bugs.debian.org (full text, mbox, reply):

From: Andreas Henriksson <andreas@fatal.se>

To: 504787@bugs.debian.org

Subject: Re: manpages-dev: getpwnam_r does not return an error for non-existent user

Date: Fri, 07 Nov 2008 18:45:16 +0100

Sorry, noticed that there already is a description about it if you look
close enough in the "DESCRIPTION" section. I guess I'm not alone to jump
straight to the "RETURN" section and it would be nice with a small
pointer there, right after....

"The getpwnam_r() and getpwuid_r() functions return zero on success.  In
case of error, an error number is returned."


Feel free to disagree and close this report. I don't feel strongly about
it, just thought it might help others to not make the same mistake I
did.

-- 
Regards,
Andreas Henriksson

Message #15 received at 504787@bugs.debian.org (full text, mbox, reply):

From: "Michael Kerrisk" <mtk.manpages@googlemail.com>

To: "Andreas Henriksson" <andreas@fatal.se>, 504787@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: Bug#504787: manpages-dev: getpwnam_r does not return an error for non-existent user

Date: Fri, 7 Nov 2008 16:10:52 -0500

tags 504787 fixed-upstream
thanks

Hello Andreas,

On Fri, Nov 7, 2008 at 12:45 PM, Andreas Henriksson <andreas@fatal.se> wrote:
> Sorry, noticed that there already is a description about it if you look
> close enough in the "DESCRIPTION" section. I guess I'm not alone to jump
> straight to the "RETURN" section and it would be nice with a small
> pointer there, right after....
>
> "The getpwnam_r() and getpwuid_r() functions return zero on success.  In
> case of error, an error number is returned."
>
>
> Feel free to disagree and close this report. I don't feel strongly about
> it, just thought it might help others to not make the same mistake I
> did.

Actually, I'll feel free to strongly agree with you.  The page could
be rather clearer on this point.

I made the change below, which also makes other details more explicit,
for upstream man-pages-3.14.  I also made an analogous change in
getgrnam.3.

Thanks for your report!

Cheers,

Michael

--- a/man3/getpwnam.3
+++ b/man3/getpwnam.3
@@ -142,15 +142,21 @@ by subsequent calls to
 .BR getpwnam (),
 or
 .BR getpwuid ().
 .LP
-The
+On success,
 .BR getpwnam_r ()
 and
 .BR getpwuid_r ()
-functions return
-zero on success.
-In case of error, an error number is returned.
+return zero, and set
+.IR *pwbufp
+to
+.IR pwbuf .
+If no matching password record was found,
+these functions return 0 and store NULL in
+.IR *pwbufp .
+In case of error, an error number is returned, and NULL is stored in
+.IR *pwbufp .
 .SH ERRORS
 .TP
 .BR 0 " or " ENOENT " or " ESRCH " or " EBADF " or " EPERM " or ... "
 The given

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Message #22 received at 504787@bugs.debian.org (full text, mbox, reply):

From: "Michael Kerrisk" <mtk.manpages@googlemail.com>

To: "Andreas Henriksson" <andreas@fatal.se>, 504787@bugs.debian.org

Subject: Re: Bug#504787: manpages-dev: getpwnam_r does not return an error for non-existent user

Date: Fri, 7 Nov 2008 17:03:54 -0500

And to make things crystal clear, I've added this example to the man page.

#include <pwd.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>

int
main(int argc, char *argv[])
{
    struct passwd pwd;
    struct passwd *result;
    char *buf;
    size_t bufsize;
    int s;

    if (argc != 2) {
        fprintf(stderr, "Usage: %s username\n", argv[0]);
        exit(EXIT_FAILURE);
    }

    bufsize = sysconf(_SC_GETPW_R_SIZE_MAX);
    if (bufsize == -1)          /* Value was indeterminate */
        bufsize = 16384;        /* Should be more than enough */

    buf = malloc(bufsize);
    if (buf == NULL) {
        perror("malloc");
        exit(EXIT_FAILURE);
    }

    s = getpwnam_r(argv[1], &pwd, buf, bufsize, &result);
    if (result == NULL) {
        if (s == 0)
            printf("Not found\n");
        else {
            errno = s;
            perror("getpwnam_r");
        }
        exit(EXIT_FAILURE);
    }

    printf("Name: %s; UID: %ld\n", pwd.pw_gecos, (long) pwd.pw_uid);
    exit(EXIT_SUCCESS);
}

Message #27 received at 504787-close@bugs.debian.org (full text, mbox, reply):

From: Joey Schulze <joey@infodrom.org>

To: 504787-close@bugs.debian.org

Subject: Bug#504787: fixed in manpages 3.14-1

Date: Sat, 29 Nov 2008 11:17:11 +0000

Source: manpages
Source-Version: 3.14-1

We believe that the bug you reported is fixed in the latest version of
manpages, which is due to be installed in the Debian FTP archive:

manpages-dev_3.14-1_all.deb
  to pool/main/m/manpages/manpages-dev_3.14-1_all.deb
manpages_3.14-1.diff.gz
  to pool/main/m/manpages/manpages_3.14-1.diff.gz
manpages_3.14-1.dsc
  to pool/main/m/manpages/manpages_3.14-1.dsc
manpages_3.14-1_all.deb
  to pool/main/m/manpages/manpages_3.14-1_all.deb
manpages_3.14.orig.tar.gz
  to pool/main/m/manpages/manpages_3.14.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 504787@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Joey Schulze <joey@infodrom.org> (supplier of updated manpages package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sat, 29 Nov 2008 12:01:13 +0100
Source: manpages
Binary: manpages manpages-dev
Architecture: source all
Version: 3.14-1
Distribution: unstable
Urgency: low
Maintainer: Martin Schulze <joey@debian.org>
Changed-By: Joey Schulze <joey@infodrom.org>
Description: 
 manpages   - Manual pages about using a GNU/Linux system
 manpages-dev - Manual pages about using GNU/Linux for development
Closes: 504699 504787 506299
Changes: 
 manpages (3.14-1) unstable; urgency=low
 .
   * New upstream version
     . Fix description of range of function value return in atan2(3)
       (closes: Bug#506299)
     . Clarify and add more detail in RETURN VALUE description in
       getpwnam(3) and getgrnam(3) (closes: Bug#504787)
     . Add text on use of pointer arguments to makecontext(3) (closes:
       Bug#504699)
     . Document that LOG_KERN messages can't be generated from user
       processes in syslog(3)
   * Avoid distribution of more pthread manpages that are currently also
     provided by glibc-doc:
     . pthread_attr_setinheritsched(3)
     . pthread_cancel(3)
     . pthread_cleanup_pop(3)
     . pthread_cleanup_push(3)
     . pthread_setcancelstate(3)
     . pthread_setcanceltype(3)
     . pthread_testcancel(3)
Checksums-Sha1: 
 24893a0610d560906b338402596dd61625b3cb23 964 manpages_3.14-1.dsc
 f69bdd0ab2fe373a266809905b40e5e1ef6427d5 1520978 manpages_3.14.orig.tar.gz
 d04ba3dfb8a3fe897539c471bca78ceec07e6b5c 49494 manpages_3.14-1.diff.gz
 121fae93537754ee85d5d52b9a70c23fa9f61fc8 650242 manpages_3.14-1_all.deb
 71e58f698ea1a8f6fe3ade522eb15702475a9698 1522358 manpages-dev_3.14-1_all.deb
Checksums-Sha256: 
 d06a5b800d6d42b11fe3c4c58bea1972bfbd4fe4807e99531acebaab912e9919 964 manpages_3.14-1.dsc
 e93c51c18329484b0fe9d7b6d6bd1c57bcaabcab97aca06e570eb963f330d355 1520978 manpages_3.14.orig.tar.gz
 0dfe78de3db50a53a43482623c4609420fa941431f7178190fd03d358b6c380d 49494 manpages_3.14-1.diff.gz
 0eb9bf2d24336f5d1521b0d63e9d2f897cc9669bbc754be06e525d4e2b03b1d8 650242 manpages_3.14-1_all.deb
 b4b64abbb972f0eb840fe6871e8aeed4aad23378ed9e6ce0afc8ac210b8586c2 1522358 manpages-dev_3.14-1_all.deb
Files: 
 6f99cf576d6c6f78e1b127ff13c018ea 964 doc important manpages_3.14-1.dsc
 356983f0fc29e0a221f576d979a09d02 1520978 doc important manpages_3.14.orig.tar.gz
 4c67932cc6b7e7785c105b3c91b38e9b 49494 doc important manpages_3.14-1.diff.gz
 84baa24ec0cdb4815373703e2d2eeba2 650242 doc important manpages_3.14-1_all.deb
 ee20b1ea55967cd29d4ffd26e9b35e20 1522358 doc optional manpages-dev_3.14-1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFJMSGWW5ql+IAeqTIRAgD/AJ90bJA8DssEO8veGT60ADAPuWl4SQCdHU4u
tM3lixpjlK000EtX8FBt7nI=
=cwsx
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.