Bug report

When is available:O_TMPFILE

1. tempfile.TemporaryFile(mode='wb') opens with instead of , the callback ignores argument and always use O_RDWR``O_WRONLY``opener``mode``_bin_openflags
2. _bin_openflags has both and set, the callback removes from flags but leave , this is an undefined behavior according to Linux manpageO_CREAT``O_EXCL``opener``O_CREAT``O_EXCL``open(2)

Your environment

• CPython versions tested on: 3.10
• Operating system and architecture: Linux x86_64

Perhaps you can provide the minimum test sample.

The first issue means a temporary file opened write-only can be read via the underlying file descriptor, which doesn't seem ideal, and might theoretically be a security concern if the user was passing it somewhere untrusted (e.g. to use as a write-only log channel), although that seems very unlikely.

import os, tempfile
with tempfile.TemporaryFile(mode='ab') as t:
    t.write(b'abc')
    t.seek(0)
    print(os.read(t.fileno(), 3)) # b'abc'

Fixing this will break any code that relies on temporary files always being implicitly readable on systems with O_TMPFILE, of course.

I think the second issue is not actually a bug, although the Linux man pages are arguably ambiguous, so this is open to interpretation. With regards O_EXCL they say:

In general, the behavior of O_EXCL is undefined if it is used without O_CREAT. There is one exception [...which isn't O_TMPFILE...]

However, it also says with regards O_TMPFILE:

Specifying O_EXCL in conjunction with O_TMPFILE prevents a temporary file from being linked into the filesystem in the above manner. (Note that the meaning of O_EXCL in this case is different from the meaning of O_EXCL otherwise.)

IMO the second bit should be read as a specific exception to the general rule in the first bit, and hence the behaviour is not undefined in this case. This matches with usage I could find with a quick code search: O_TMPFILE | O_EXCL without O_CREAT is much more common than O_TMPFILE | O_CREAT (with or without O_EXCL).

• Duplicate of #133236 /

• Duplicate of #133236 /

That doesn't look like the right issue: could you double-check the number, please?