From: Florian Weimer <fweimer@redhat.com>
To: Rich Felker <dalias@libc.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: Proposal to fix pwrite with O_APPEND via pwritev2 flag
Date: Fri, 24 Jan 2020 10:37:22 +0100 [thread overview]
Message-ID: <87d0b942lp.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <20200124000243.GA12112@brightrain.aerifal.cx> (Rich Felker's message of "Thu, 23 Jan 2020 19:02:43 -0500")
* Rich Felker:
> There's a longstanding unfixable (due to API stability) bug in the
> pwrite syscall:
>
> http://man7.org/linux/man-pages/man2/pwrite.2.html#BUGS
>
> whereby it wrongly honors O_APPEND if set, ignoring the caller-passed
> offset. Now that there's a pwritev2 syscall that takes a flags
> argument, it's possible to fix this without breaking stability by
> adding a new RWF_NOAPPEND flag, which callers that want the fixed
> behavior can then pass.
>
> I have a completely untested patch to add such a flag, but would like
> to get a feel for whether the concept is acceptable before putting
> time into testing it. If so, I'll submit this as a proper patch with
> detailed commit message etc. Draft is below.
Has this come up before?
I had already written a test case and it turns out that an O_APPEND
descriptor does not protect the previously written data in the file:
openat(AT_FDCWD, "/tmp/append-truncateuoRexJ", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
write(3, "@", 1) = 1
close(3) = 0
openat(AT_FDCWD, "/tmp/append-truncateuoRexJ", O_WRONLY|O_APPEND) = 3
ftruncate(3, 0) = 0
So at least it looks like there is no security issue in adding a
RWF_NOAPPEND flag.
Thanks,
Florian
next prev parent reply other threads:[~2020-01-24 9:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-24 0:02 Proposal to fix pwrite with O_APPEND via pwritev2 flag Rich Felker
2020-01-24 9:37 ` Florian Weimer [this message]
2020-01-24 14:07 ` Rich Felker
[not found] ` <20200124000243.GA12112-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org>
2020-02-05 4:42 ` Rich Felker
2020-02-05 4:42 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d0b942lp.fsf@oldenburg2.str.redhat.com \
--to=fweimer@redhat.com \
--cc=dalias@libc.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.