[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