linux-kernel - Re: [PATCH 2/4] configfs: Fix writing at a non-zero offset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4055ca70-7669-d00d-7c08-86fe75a3d377@gmail.com>
Date:   Mon, 26 Jul 2021 23:13:03 +0200
From:   Bodo Stroesser <bostroesser@...il.com>
To:     Bart Van Assche <bvanassche@....org>,
        Christoph Hellwig <hch@....de>
Cc:     Joel Becker <jlbec@...lplan.org>, linux-kernel@...r.kernel.org,
        "Martin K . Petersen" <martin.petersen@...cle.com>,
        Yanko Kaneti <yaneti@...lera.com>,
        Brendan Higgins <brendanhiggins@...gle.com>
Subject: Re: [PATCH 2/4] configfs: Fix writing at a non-zero offset

On 26.07.21 18:26, Bart Van Assche wrote:
> On 7/26/21 7:58 AM, Bodo Stroesser wrote:
>> On 23.07.21 23:23, Bart Van Assche wrote:
>> Let's say user writes 5 times to configfs file while keeping it open.
>> On every write() call it writes 1 character only, e.g. first "A", then 
>> "B", ...
>>
>> The original code before the changes 5 times called flush_write_buffer 
>> for the
>> strings "A\0", "B\0", ... (with the '\0' not included in the count 
>> parameter,
>> so count is 1 always, which is the length of the last write).
> 
> Isn't that behavior a severe violation of how POSIX specifies that the 
> write() system call should be implemented?

Hmm. I'm not sure which detail should violate POSIX spec? Is there any
definition how data should be flushed from buffer internally? (I'm by
far not a POSIX expert!)

I would rather say the new behavior, to call flush_write_buffer during the
first write() for the data of that write, and then on the second write to
call flush_write_buffer for the concatenated data of the first and the
second write, could be a violation of POSIX, because the one times written
data of the first write is flushed twice.

I don't like the idea of breaking the "one write, one flush" principle that
was implemented before. The old comment:
"There is no easy way for us to know if userspace is only doing a partial
write, so we don't support them. We expect the entire buffer to come on the
first write."
as I interpret it, makes clear that configfs code has to work according to
that principle. (Or even block all but the first write, but that would even
more break compatibility to old implementation.)

Thank you,
Bodo