| 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
| ||
|
Message-ID: <yw1x1vsg4jio.fsf@thrashbarg.mansr.com> Date: Sun, 29 Mar 2009 13:10:23 +0100 From: Måns Rullgård <mans@...sr.com> To: "Andreas T.Auer" <andreas.t.auer_lkml_73537@...us.ath.cx> Cc: linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org Subject: Re: Zero length files - an alternative approach? "Andreas T.Auer" <andreas.t.auer_lkml_73537@...us.ath.cx> writes: > On 29.03.2009 13:22 Måns Rullgård wrote: >> Consider this scenario: >> >> 1. Create/write/close newfile >> 2. Rename newfile to oldfile >> 3. Open/read oldfile. This must return the new contents. >> 4. System crash and reboot before delayed allocation/flush complete >> 5. Open/read oldfile. Old contents now returned. >> >> This rollback isn't obviously, to me at least, without problems of its >> own. >> > Having the old data in 5) is far better than having no data in 5). Of course having old data is better than no data. However, fsync() and similar approaches make a rollback to old data after new data has been visible impossible or far less likely than the suggested one. I'm not saying it's necessarily a problem, only that it is a difference that should be taken into account. -- Måns Rullgård mans@...sr.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists