linux-ext4 - [Q] e4defrag and append-only files

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-next>] [day] [month] [year] [list]

Message-ID: <a2b2fcf4-4b71-e78c-5a10-627097df44fb@virtuozzo.com>
Date:   Mon, 9 Dec 2019 13:54:24 +0300
From:   Kirill Tkhai <ktkhai@...tuozzo.com>
To:     linux-ext4@...r.kernel.org
Cc:     tytso@....edu, jack@...e.com, adilger.kernel@...ger.ca,
        ktkhai@...tuozzo.com
Subject: [Q] e4defrag and append-only files

Hi,

on one of production nodes I observe the situation, when many fragmented files
never become defragmented, becase of they have "a" extended attribute.
The reason is append-only file can't be open for write without O_APPEND attribute:

$lsattr a.txt
-----a--------e----- a.txt

$strace e4defrag a.txt
openat(AT_FDCWD, "a.txt", O_RDWR)       = -1 EPERM (Operation not permitted)

Simple O_APPEND passed to open() solves the situation.

The question is: can't we just do this?

Let's observe the file restrictions we may have.

"Append-only" extended attribute restriction is weaker, than RO file permissions (0444).
But RO files are being processed by e4defrag, since e4defrag runs by root, and it easily
ignores RO file permissions, while "append-only" files are always ignored by the util.
Is there a fundamental reason we must skip them?

Thanks,
Kirill