[Mono-dev] [PATCH] Bug in Mono.Posix handling '+::::::' entry in /etc/passwd

Jonathan Pryor jonpryor at vt.edu
Thu Apr 30 13:23:02 EDT 2009


On Thu, 2009-04-30 at 07:45 -0700, Ian Dichkovsky wrote:
> Thank you for the advices.
> We have discussed NIS configuration with our SA gang. They changed line in
> /etc/nsswitch.conf from
> passwd:      files nis
> to
> passwd:      compat
> 
> In this case test NonReentrantSyscalls passed successfully.
> 
> Beside that we tried to return to "passwd:      files nis" and play a bit
> with functions getpwent() and getpwnam().
> While getpwent() returns user "+" at the same time getpwnam("+") returns
> NULL-pointer and errno is set to 0.
> Man says, that this is a correct behavior of getpwnam() in case of missing
> user.
> So, do we accept this behavior of getpwnam("+") and should fix the sources
> of test or leave it with configuration workaround?

Leave it with the "configuration workaround", as it's not a workaround,
it's fixing an invalid (or at least unsupported) configuration.

getpwnam("+") is failing because there is no such user "+", just as
getpwnam("-") and getpwnam("ThisUserDoesNotExist") will fail... as those
users do not exist.  This is expected, documented, behavior.

getpwnam(3) isn't the problem.  getpwent(3) is, arguably.

getpwent(3) really shouldn't be returning a "+" user under "files nis"
because that's really not valid, so it's arguably a getpwent(3) bug.
(For comparison, an /etc/passwd entry of "invalid::::::" isn't returned
by getpwent(3), and under "compat" settings an /etc/passwd entry of
"+:::::" causes getpwent(3) to immediately return NULL.)

I don't want to get into the habit of "fixing" underlying libraries from
managed code, as today's fix will be tomorrow's bug (when the underlying
libraries is fixed and/or extended so that the now "bad" behavior is
instead a "feature").

 - Jon




More information about the Mono-devel-list mailing list