unexpected behavior of tempfile.TemporaryFile() for O_TMPFILE

[zhangyoufu]

Bug report

When O_TMPFILE is available:

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

Your environment

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

Linked PRs

• gh-96531: tempfile.TemporaryFile should honour write-only mode #133235

[rruuaanng]

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.

[duaneg]

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).

[duaneg]

• Duplicate of #133236 /

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

[serhiy-storchaka]

I am not sure what is a practical reason to do this.

Note that "a" in the mode does not make the flags using O_APPEND, and O_EXCL is always used even without "x" in the mode. There is no direct relation between the mode and the open flags like in io.open().

[duaneg]

I am not sure what is a practical reason to do this.

I guess the OP can let us know if this caused a real issue or was a theoretical concern they stumbled on. As mentioned above, the only scenario I could think of where this might cause trouble is something like code that wants to pass a write-only file descriptor to a temporary file to an untrusted child process: a rather contrived and unlikely situation. It could also be easily worked-around by re-opening the file write-only after it is created (which is probably more robust and a better approach anyway).

Note that "a" in the mode does not make the flags using O_APPEND, and O_EXCL is always used even without "x" in the mode. There is no direct relation between the mode and the open flags like in io.open().

Yes, and the lack of support for O_APPEND makes the scenario above even less likely (or rather, in any situation where the descriptor being readable is an issue, it being seekable is probably also an issue).

On the other other hand, making file access write-only at the OS level when the user asks for write-only access just seems like a good idea in general, and is relatively easy to do, as can be seen from the small and simple patch.

If you think this isn't worth the potential risk (e.g. of code that currently relies on such a file being readable despite opened write-only) I am happy to withdraw the PR, in which case I guess this ticket should be closed as "not planned".

[zhangyoufu]

There is no direct relation between the mode and the open flags like in io.open().

The default value 'w+b' for parameter mode make me think that it should have the same semantic as the built-in open function. If we only want to differentiate between text/binary mode, and the r/w/a/+ has no effect, it should be made clear in the doc.

pass a write-only file descriptor to a temporary file to an untrusted child process

Yes. That's exactly what I want to do.

It could also be easily worked-around by re-opening the file write-only after it is created (which is probably more robust and a better approach anyway).

Agree. I could dup its fd and use fcntl w/ F_SETFL to switch between O_RDWR and O_WRONLY. It may worth being implemented as a helper function in class tempfile.TemporaryFile for situations that need precise read/write control. (pass the fd to somewhere else, like exec or unix socket)