linux-ext4 - Re: Atomic non-durable file write API

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: <AANLkTimxbjEntSBYxzxnHnOOCUkdNyGWJ40HGG=0d0E5@mail.gmail.com>
Date:	Tue, 28 Dec 2010 17:00:55 -0500
From:	Greg Freemyer <greg.freemyer@...il.com>
To:	Neil Brown <neilb@...e.de>
Cc:	Olaf van der Spek <olafvdspek@...il.com>,
	Christian Stroetmann <stroetmann@...olinux.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-ext4@...r.kernel.org, "Ted Ts'o" <tytso@....edu>,
	Nick Piggin <npiggin@...il.com>
Subject: Re: Atomic non-durable file write API

On Tue, Dec 28, 2010 at 3:59 PM, Neil Brown <neilb@...e.de> wrote:
> On Tue, 28 Dec 2010 18:22:42 +0100 Olaf van der Spek <olafvdspek@...il.com>
> wrote:
>
>> On Mon, Dec 27, 2010 at 8:30 PM, Christian Stroetmann
>> <stroetmann@...olinux.com> wrote:
>> > Btw.: There is even no analogy: "The concepts are the same".
>>
>> So? Doesn't mean you implement full ACID DB-like transactions.
>>
>> >>>> Still waiting on any hint for why that performance loss would happen.
>> >>>
>> >>> > From my point of view, the loss of performance depends on what is
>> >>> benchmarked in which way.
>> >>
>> >> Maybe, but still no indication of why.
>> >
>> > If you have a solution, then you really should show other persons the
>> > working source code.
>>
>> I don't have source code.
>> Are you not capable of reasoning about something without having
>> concrete source code?
>>
>> > For me speaking: I like such technologies and I'm also interested in your
>> > attempts.
>>
>> Writing code is a lot of work and one should have the design clear
>> before writing code, IMO.
>
> Yes and no.
>
> Having some design is obviously important before starting to code.
> However it is a common experience that once you start writing code, you start
> to see all the holes in your design - all the corner cases that you didn't
> think about.  So sometimes writing some proof-of-concept code is a very
> valuable step in the design process.
> Then of course you need to do some testing to see if in the code actually
> performs as hoped or expected.  That testing may cause the design to be
> revised.
> So asking for code early is not necessarily a bad thing.
>
> I think the real disconnect here is that you haven't really established or
> justified a need.
>
> You seem to be asking for the ability to atomically change the data in a file
> without changing the metadata.  I cannot see why you would want this.  Maybe
> you could give an explicit use-case??

==> joining the thread

I assumed the use case was one of simple document editor.

If I am working on a office doc with oowriter as an example, I don't
want a system crash or out of diskspace to kill my original doc.  7 or
8 years ago XFS used to zero out the file in situations like that.
Hopefully that's fixed.

What I don't understand is what the security impacts are of the file
owner changing.  ie. Assume user 1 creates a word doc, then user 2
makes an edit.  If the owner is changed to the second user, is that a
problem?

Same for the group?

Personally I'd rather see it stay with the original owner / group.

I assume the solution today that oowriter etc. use is:

===
create temp file
write out new data
delete old file
rename temp file to primary name
===

If so there is still a little window of vulnerability where the whole
file can be lost.  (Or at least only the temp file is present).

Text editors, xml editors, etc. seem like they all have the same vulnerability.

If my assumptions are right, then a way to guarantee either the old or
new file contents are available after a crash would be useful.

== EXT4_IOC_MOVE_EXT

There was mention of this ioctl earlier in the thread.

I don't think it guarantees all or nothing data replacement as
requested here.  It is designed with defragment as the primary use
case.

As such it steps through data blocks and replaces them, but if only
half the blocks get replaced with new ones due to a crash, it is not a
big deal.

Greg
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html