Issue 36161: Use thread-safe functions instead of unsafe ones (crypt, ttyname) (original) (raw)

(good first issue, I think.)

CPython currently uses a few functions that are thread-unsafe where thread-safe version exist, at least in glibc (crypt() and ttyname(), at least). This isn't an issue when looking at CPython in isolation because these calls are guarded by the GIL, but it can be a problem if the C functions are called from other code (in an extension module, or from an application embedding CPython).

I expect it to be uncommon to be the case with crypt() and ttyname(), so it's probably not important to fix, but I do think these would make good first issues. crypt(), in particular, is called from a very self-contained (and otherwise) module, and could do with some other enhancements (proper error handling, properly #including crypt.h).

I suggest a new contributor (or someone new to C) take this on and do something like the following, using crypt as an example:

• Add configure.ac checks for crypt.h and crypt_r()
• In Modules/_cryptmodule.c, if present, import crypt.h and use crypt_r.
• Check for a NULL return and raise OSerror, but possibly only when using crypt_r() (for compatibility with systems where crypt() doesn't do the right thing on error, perhaps).
• Add tests for the new error handling (crypt() on glibc will return an error on invalid salts).

For ttyname() (called from Modules/posixmodule.c), the change would be simpler (it already handles errors), but a choice will have to be made about the size of the buffer to use, and whether to use a static buffer (which would be protected by the GIL).

There may be other functions being used in posixmodule or other modules that could conflict with non-CPython uses of the thread-unsafe functions that we could switch to thread-safe versions, but other than manually looking I'm not sure yet how to find them.

In Issue 28503, “crypt_r” was added to Python 3.7 and 3.8+, and it looks like it is still there.

Regarding error handling for “crypt”, it is not documented, but the Python function returns None on error. You would have to consider backwards compatibility to use OSError. Perhaps add a new parameter like “crypt(raise_error=True)”?

Ah, looks like I missed crypt_r getting added in 3.7. Sorry about that. Yes, the error handling would be a behaviour change, a keyword argument may be a good solution. As it is, crypt() returns None, throwing away the reason for the failure (which is recorded in errno).