linux-ext4 - Re: [PATCH v8 09/19] fsnotify: generate pre-content permission event on truncate

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: <20241120152340.gu7edmtm2j3lmxoy@quack3>
Date: Wed, 20 Nov 2024 16:23:40 +0100
From: Jan Kara <jack@...e.cz>
To: Josef Bacik <josef@...icpanda.com>
Cc: kernel-team@...com, linux-fsdevel@...r.kernel.org, jack@...e.cz,
	amir73il@...il.com, brauner@...nel.org,
	torvalds@...ux-foundation.org, viro@...iv.linux.org.uk,
	linux-xfs@...r.kernel.org, linux-btrfs@...r.kernel.org,
	linux-mm@...ck.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH v8 09/19] fsnotify: generate pre-content permission event
 on truncate

On Fri 15-11-24 10:30:22, Josef Bacik wrote:
> From: Amir Goldstein <amir73il@...il.com>
> 
> Generate FS_PRE_ACCESS event before truncate, without sb_writers held.
> 
> Move the security hooks also before sb_start_write() to conform with
> other security hooks (e.g. in write, fallocate).
> 
> The event will have a range info of the page surrounding the new size
> to provide an opportunity to fill the conetnt at the end of file before
> truncating to non-page aligned size.
> 
> Signed-off-by: Amir Goldstein <amir73il@...il.com>

I was thinking about this. One small issue is that similarly as the
filesystems may do RMW of tail page during truncate, they will do RMW of
head & tail pages on hole punch or zero range so we should have some
strategically sprinkled fsnotify_truncate_perm() calls there as well.
That's easy enough to fix.

But there's another problem which I'm more worried about: If we have
a file 64k large, user punches 12k..20k and then does read for 0..64k, then
how does HSM daemon in userspace know what data to fill in? When we'll have
modify pre-content event, daemon can watch it and since punch will send modify
for 12k-20k, the daemon knows the local (empty) page cache is the source of
truth. But without modify event this is just a recipe for data corruption
AFAICT.

So it seems the current setting with access pre-content event has only chance
to work reliably in read-only mode? So we should probably refuse writeable
open if file is being watched for pre-content events and similarly refuse
truncate?

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR