linux-ext4 - Re: Atomic file data replace 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]

Date:	Wed, 29 Dec 2010 11:20:17 +0200
From:	Amir Goldstein <amir73il@...il.com>
To:	Olaf van der Spek <olafvdspek@...il.com>
Cc:	Ric Wheeler <rwheeler@...hat.com>, "Ted Ts'o" <tytso@....edu>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-ext4@...r.kernel.org
Subject: Re: Atomic file data replace API

On Wed, Dec 29, 2010 at 12:58 AM, Olaf van der Spek
<olafvdspek@...il.com> wrote:
> On Tue, Dec 28, 2010 at 11:36 PM, Ric Wheeler <rwheeler@...hat.com> wrote:
>> I think that various developers have answered this for you several times.
>
> Not really, unfortunately. Haven't seen a single link to code that
> shows how to do it properly.
> Temp file, fsync, rename is often mentioned but that skips the
> preserving meta-data part and this part, which you also skipped:
> One use case would be updating a file in a safe way when you have
> write access to that file but not to anything else.
>

I think it is safe to say that the *only* option you have now is "temp
file, fsync, rename".
There is no "generic atomic file data replace API in Linux", though it
is available via
private ioctl for XFS and EXT4.

You have started a bit of a storm with your previous thread, which
doesn't help you
much in moving forward in the current thread (previous thread is still
more popular).
I suggest that you humbly swallow you need to know WHY is it hard to implement
non-durable atomic API and focus your attention on the very achievable
data replace API.

IMHO, implementing atomic swap_inodes_data operation shouldn't be difficult
in most file systems (only implementation is simple, but testing and
maintaining
is not to be taken lightly).
Something along the lines of:
1. aquire inodes write/truncate locks
2. start transaction
3. check/update quota limits
4. swap inodes i_data content
5. invalidate (or swap?) inodes page caches
6. mark inodes dirty
7. end transaction & release locks

The real challenge would be to get everyone to agree on a common API
and carve it in stone to the kernel's ABI (is it just swap_inodes_data?
maybe also swap_inode_data_ranges? what about some options?)

Also, as wacky and (some say) faulty the UNIX permissions models is,
current systems have grown old with it, and even 'improving' the behavior
of some applications, may wake up sleeping monsters, so it will not
be done until enough people have pointed out security or usability
issues, which could not be solved otherwise.

In other words, until you find an *application* that wants to allow other
user to modify the content of a file and preserve it's metadata and ownership.
And unless that application cannot find a better way to achieve what it wanted
to do in the first place, or unless that application already has a
large install base
which suffers from *a problem*, you will not have proven *the need*.

Maybe preserving privileged extended attributes is *a need*.
I wouldn't know myself.

Amir.
--
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