Agreed. But that does not mean that tmpfile() should create a file with 0 perms on it. Which makes file unusable.But since tmpfile() doesn't appear to be labelled MT-safe, I doubt it'll be considered a bug.
Let me clear the confusion. Let's say thread 1 calls tmpfile()->common->umask(0777) and just returned for umask() call. Now thread 2 calls tmpfile() and returns before thread 1 enters second umask() tmpfile()->common->umask(current_mask). If you see it's not in userland. All inside tmpfile() called from two threads. The sample test code I provided was just copied from _common(). Thread 2 returns a file with 0 perms on it.And I'm not sure why the implementation is using umask() anyway. Why not just create the temp file with 0600 permissions and let it go at that? If you do a truss of the tmpfile() call, you see the file gets unlinked immediately anyway.
I'm also curious as to what impact this has in reality. IIRC (and it has been a while...) since the file descriptor was created upon opening as read/write, that original file descriptor should be usable to read/write the file as needed no matter what the permissions are set to later.