This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2] linux: open and openat ignore 'mode' with O_TMPFILE in flags


On Sun, Nov 2, 2014 at 8:44 AM, Rich Felker <dalias@libc.org> wrote:
> It's unlikely that such a flag will ever be added again, and it really
> should not have happened with O_TMPFILE. O_TMPFILE is fundamentally a
> "create" operation and should have either requried O_CREAT with it, or
> had O_CREAT built into the bits of its definition. This was an
> oversight on the part of the kernel folks when they added it.

For reference, that was actually entirely deliberate (original
discussion at http://thread.gmane.org/gmane.linux.file-systems/76261).
They were looking for a flag combination that would guarantee that
O_TMPFILE would fail on older kernels.

When using O_TMPFILE to implement a secure temporary file facility,
you don't want
        fd = open("$TMPDIR", O_TPMFILE, 0600);
to succeed as a regular O_CREAT on an older kernel that doesn't know
about O_TMPFILE, yet finds the O_CREAT bit in flags, and creates a
visible file, when TMPDIR doesn't exist (any manual check beforehand
would necessarily be racy). open() has traditionally never checked for
unknown bits set in flags.

Some have argued (then and since) that this should have been a hint
that open() was the wrong place to add such a facility, and that a
tmpfile() syscall should have been added instead, with its own
separate semantics.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]