[Bug libc/17523] open() and openat() ignore 'mode' with O_TMPFILE

["e at nanocritical dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17523

--- Comment #5 from Eric Rannaud <e at nanocritical dot com> ---
On x64_64:

  - open("/tmp", O_TMPFILE|O_WRONLY, 0600): the mode gets magically passed
correctly to the kernel, at least with the code generated by a "current" GCC
for glibc, at the "typical" optimization level for my distribution (Arch).

  - openat(AT_FDCWD, "/tmp", O_TMPFILE|O_WRONLY, 0600): the kernel gets
whatever happens to be in R10.

On other architectures, what mode the kernel sees really depends on the exact
code generated by the compiler, the calling conventions (userspace vs.
syscall), the exact glibc wrapper and whether nocancel or not.

It's possible the kernel reads an arbitrary mode value on non-x86_64 too.

Now, Florian is correct that the file created by O_TMPFILE is not immediately
visible on the filesystem. BUT, O_TMPFILE is likely to be used in the following
sequence, to implement a secure temporary file facility:

    fd = open("/path/to/dir", O_TMPFILE|O_WRONLY, 0600);
    snprintf(path, PATH_MAX,  "/proc/self/fd/%d", fd);
    linkat(AT_FDCWD, path, AT_FDCWD, "/path/for/file", AT_SYMLINK_FOLLOW);

Now, the file /path/for/file is created with an undefined mode, not 0600. A
workaround for such an implementation is to follow the open with an explicit
    fchmod(fd, 0600)

Also, the fortify wrappers are rendered ineffectual in the O_TMPFILE case.

So I believe this issue does have security implications.


Note: the kernel had a related issue, where the syscalls open/openat with
O_TMPFILE would fail with EACCES if mode was 0. A patch has gone in Linux
3.18-rc3 to allow that usage.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=69a91c237ab0ebe4e9fdeaf6d0090c85275594ec

-- 
You are receiving this mail because:
You are on the CC list for the bug.