Re: New VSI post on Youtube

On Fri, 23 Aug 2024 00:12:18 +0100, chrisq wrote:

Problem is that of you return a pointer, that suggests that the struct
has been declared static inside the called function. That would be a
fail for reentant code that might be called from elsewhere, say, from an
interrupt handler, or another thread. The struct would  typically be on
the stack or heap, and would disappear on return from the call, making
the return value invalid. Ideally, in a multitasking os, all code should
be designed to be fully reentrant, to make it safe in all situations.

One notorious POSIX-related example is the crypt(3) function
<https://manpages.debian.org/3/crypt.3.en.html>.

I was helping a client reinstall some old proprietary app that had
been running on an ancient machine that had crashed. For the new
setup, we thought we’d try a slightly less ancient version of Debian
(I think the original machine had been running Debian 4). But logins
wouldn’t work. Even worse, the errors didn’t make sense: instead of
saying that the username or password was invalid, it was reporting
something crazy like errors to do with SELinux or something (we
weren’t using SELinux).

Finally, I made a wild, desperate guess: the code was copying the
result from the crypt call into a fixed-size buffer, which wasn’t big
enough to hold the hash for newer password algorithms. This was
leading to a buffer overflow when hashing perfectly valid passwords,
which in turn was corrupting some data elsewhere and triggering the
spurious errors.

So I had to try and find an older algorithm that the system still
supported, which would bring the hash size within range, and use that
hash for the relevant passwords.

And that worked.

You’ll see from the above man page that POSIX has no official solution
to this problem: there are calls available in Linux (courtesy of the
Openwall project) that will use dynamically-allocated buffers; but of
course they will likely not be available on other systems that claim
to be POSIX-compatible.