Timo Sirainen:
> On 27.4.2011, at 18.04, Wietse Venema wrote:
>
> >> I think the POSIX API works in all OSes commonly used nowadays. FreeBSD
> >> 5.1, NetBSD 3.0, OpenBSD 4.4, Solaris 5(?), OS X (some version), Linux
> >> for last 5+ years.
> >> I wrote some wrappers for these and people haven't complained about them
> >> much yet (just that OpenBSD had a bug):
> >> http://hg.dovecot.org/dovecot-2.0/raw-file/tip/src/lib/ipwd.c
> >
> > Unfortunately, lack of complaints does not prove that rare errors
> > are handled correctly :-) Witness the bug that led to this thread,
> > which is at least five years old.
>
> I think the original bug was probably because of the use of
> getpwnam(). But because its API is pretty much unfixable by now
> the only realistic way to fix that is by modifying Postfix to not
> use it. So the only problems left with replacing its use with
> getpwnam_r() are:
>
> a) Does the code not compile? (Can be checked automatically at
> compile time.)
Easy enough.
> b) Does the code compile, but not actually work because of an API
> difference? (Is there such an OS where this isn't caught by a) ?)
I recall that I bored the list with a discussion that real
implementations of getpenam_r() and getpwnam() have actually evolved
over time, so what you get really depends on the system that you're
bulding on.
It is only a few years ago that Linux screwed up Postfix security
by promising POSIX semantics for link(2), when in reality they had
stopped doing that years ago. They corrected the Linux manpages by
2007, and they fixed the POSIX standard a year or so later, so
Linux no longer violates link(2) semantics.
I believe it was Victor who mentioned that SUN adopted a POSIX
draft version of getpenam_r(), and that the final standard was
different.
So, yes, code may compile, but that does not mean that it works the
same way everywhere.
> c) Does the code more or less randomly fail?
That is the wrong question. At issue here is how a system routine
reports a are kind of error. You can pretty much forget about
testing for differences in error reporting for rare errors.
Of course, I could simply mandate that people run only the latest
systems and that they always set all the flags that disable SUN,
SGI etc. default backwards compatibility (meaning it may not work
with third-party libraries that are expecting the default system
semantics).
Wietse
