bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

getpwnam() does not report ypbind errors


From: dhesi
Subject: getpwnam() does not report ypbind errors
Date: Mon, 13 Jan 2003 05:43:01 -0800 (PST)

Hi, this is a problem report.

PR #4259 reporting a problem in getpwnam() was filed in August 2002 and
closed shortly thereafter.  It was submitted as being of severity
noncritical.

This problem remains unresolved in glibc-2.2.4-31 as included in RedHat
Linux 7.2.  It is of severity quite a bit higher than noncritical.  The
problem appears when NIS is in use and when there is a temporary ypbind
failure.  The problem is not necessarily within the getpwnam() function,
but lies deeper within glibc.

When a temporary ypbind failure occurs, the library prints an error
message to stdout similar to this:

  YPBINDPROC_DOMAIN: Domain not bound

and getpwnam() returns a NULL pointer.  Even if the user being looked up
does exist in NIS, it appears to the calling code that the user does not
exist.  This can have serious consequences, e.g., incoming mail bounces
back with a "user unknown" error.  Although the library code does print
an error message, this does not help the calling code detect the error.

Since an error message is printed, it's clear that the library code is
correctly detecting the error.  It just isn't propagating it all the way
back to the code that called getpwnam().

The Open Group recommends that getpwnam() always set errno to a suitable
value when an error occurs, so the calling code can distinguish between
a nonexistent user and an error.  The value of errno should be left
undisturbed if there is no error.  A nonexistent user is not an error.

My experiments showed, however, that glibc2 always returns ENOENT when a
user cannot be found, whether or not the user really does not exist.  So
the calling code sees ENOENT even if the user exists but NIS is
temporarily broken.

Here are some possible ways of solving the problem.

1. If /etc/nsswitch.conf specifies 'passwd: compat' and if there is a
line in /etc/passwd beginning with colon, then this means that we want
to do NIS lookups.  if for some reason NIS lookups are not succeeding,
the getpwnam() function should wait until lookups begin to succeed.  The
calling code is then assured that a NULL return value from getpwnam()
really does mean that the user does not exist.  The calling code will
simply wait until NIS is functional again.

This could be made configurable.  Solaris, for example, allows the
following in nsswitch.conf:

  [TRYAGAIN=forever]     on error, keep retrying
  [TRYAGAIN=10]          on error, retry up to 10 times then continue

2. Alternatively, errno should be correctly set by getpwnam() to
indicate an error.  If a user really does not exist, then errno should
be left unchanged.  This will allow the calling code to set errno to 0,
then call getpwnam(), then check errno to find out if an error occurred.
The non-existence of a user is not an error.
-- 
Rahul Dhesi 
address@hidden (spam filtered)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]