linux-kernel - Re: [PATCH RESEND] Handle i_size > s

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: <20080123191306.GA17118@infradead.org>
Date:	Wed, 23 Jan 2008 19:13:06 +0000
From:	Christoph Hellwig <hch@...radead.org>
To:	Jan Kara <jack@...e.cz>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mark Fasheh <mark.fasheh@...cle.com>
Subject: Re: [PATCH RESEND] Handle i_size > s_maxbytes correctly

On Wed, Jan 23, 2008 at 06:54:41PM +0100, Jan Kara wrote:
>   A different solution (even with smaller impact) would be to not allow
> files with i_size > s_maxbytes in VFS at all. For local filesystems we can
> just check this on open and everything is fine

Which we should do.

> but with remote filesystems
> such as OCFS2 (or NFS) filesize can be changed on the fly from a different
> machine. So to avoid problems we can either introduce some locking to
> prevent changes of i_size from other machines while we are in critical
> sections (awww, I really don't think this is better) or truncate i_size to
> s_maxbytes when we update i_size from what we've received via network /
> shared storage (but then we'd have to track whether user truncated file to
> some size or whether fs truncated it just for safety and apps could be
> confused too). So I don't think this is really feasible.

The right fix for cluster filesystem is to have a coherent maximum file
size for the whole cluster.  If that can't be done due to protocol
reason we need to lock around i_size update and revoke access to the
inode on the client that doesn't support it.  Which of course would
require a working revoke to start with..

--
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/