This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [COMMITTED] manual/filesys.texi: O_WRONLY files also fail with EBADF when used with posix_fallocate emulation.
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 22 Oct 2015 21:42:35 +0200
- Subject: Re: [COMMITTED] manual/filesys.texi: O_WRONLY files also fail with EBADF when used with posix_fallocate emulation.
- Authentication-results: sourceware.org; auth=none
- References: <560AAF09 dot 7010407 at redhat dot com> <560AB2A5 dot 6060302 at redhat dot com>
On 09/29/2015 05:47 PM, Carlos O'Donell wrote:
> On 09/29/2015 11:32 AM, Carlos O'Donell wrote:
>> In the posix_fallocate description in the manual we list various
>> drawbacks with the emulation, including the fact that a file opened
>> with O_APPEND fails with EBADF. Similarly a file opened with O_WRONLY
>> fails with EBADF. We must be able to emulate a compare-and-swap via
>> pread/compare/pwrite in order to make the emulation as safe as possible.
>> It is not acceptable to ignore the read failure because it could result
>> in significant data loss across all of the blocks. There is no other way
>> to make this work without a true atomic CAS and SIGBUS handler (which
>> is looking more attractive as a way to remove the race condition).
>
> Just a note here, this still doesn't solve the O_WRONLY problem, because
> such an fd can't be mapped PROT_WRITE since it violates the permissions
> of file descriptor. We would need an fdreopen syscall, which doesn't exist,
> and that would open a race window where other threads might actually
> succeed at reading a file that should be write only (potential security
> risk).
fdreopen can be emulated through /proc on Linux, but it does not solve
the problem with POSIX fcntl locking semantics (because *any* close
operation by the process on the same file, not file descriptor, releases
the locks).
Florian