Bug 1969 - getgrnam() should return an unmodified errno not ENOENT
Summary: getgrnam() should return an unmodified errno not ENOENT
Status: RESOLVED INVALID
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.3.5
: P2 minor
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-02 15:41 UTC by Tobias Burnus
Modified: 2018-04-19 14:20 UTC (History)
1 user (show)

See Also:
Host: SUSE Linux 10.0 (i386) with kernel 2.6.14-20051028140608-default
Target: Configured for i686-suse-linux.
Build: Compiled on a Linux 2.6.12 system on 2005-09-09.
Last reconfirmed:
fweimer: security-

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2005-12-02 15:41:59 UTC 
getgrname() returns a POINTER, which should be NULL for no entry and for error.

According to posix, errno is set if an error occures. Since error and not found
are listed separately, a not existing entry is not an error and errno shall not
be modified.

GNU C Library stable release version 2.3.5 (20050802)
returns errno = ENOENT.

According to POSIX 2003:

"The getgrnam() function shall return a pointer to a struct group with the
structure defined in <grp.h> with a matching entry if one is found. The
getgrnam() function shall return a null pointer if either the requested entry
was not found, or an error occurred. On error, errno shall be set to indicate
the error."

The only error messages listed in SUVv3 for getgrnam are:
"[EIO]
    An I/O error has occurred.
[EINTR]
    A signal was caught during getgrnam().
[EMFILE]
    {OPEN_MAX} file descriptors are currently open in the calling process.
[ENFILE]
    The maximum allowable number of files is currently open in the system."
Comment 1 Ulrich Drepper 2005-12-02 15:57:56 UTC 
There is nothing wrong with the implementation.  The code always did signal a
missing entry with a NULL pointer and ENOENT.  There is nothing in POSIX which
prohibits this.  The POSIX spec just said what has to happen for the error
conditions.
Comment 2 Tobias Burnus 2005-12-02 16:59:46 UTC 
> There is nothing wrong with the implementation.
I disagree.

> The code always did signal a missing entry with a NULL pointer and ENOENT.
Which does not say that this is POSIX conform. 

> There is nothing in POSIX which prohibits this. The POSIX spec just said what
> has to happen for the error conditions.
I agree that it only strongly implies that errno == 0 and that it does not
completely rule out return values != 0.
I opened an Aardvark to let the Austin Group clarify this in the next revision.

I only want to point out that there are others which read POSIX the same way as
I do (from the austin-group mailing list):

"Considering the application usage on P520, L17147-17148, my
expectation would be that if no error occurs but an entry is not found,
getgrnam() returns a null pointer while getgrnam_r() returns zero and
sets the pointer pointed to by result to a null pointer and that
neither getgrnam() nor getgrnam_r() would change errno in this case.
If an error occurred, the return value is the same but errno is also
set to indicate which error was detected."
https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tpl&source=L&listname=austin-group-l&id=8929
Comment 3 Ulrich Drepper 2005-12-02 17:05:21 UTC 
Stop reopening bugs.  What desease is this?  Whether you agree or not does not
matter.  The code is correct.