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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080123194155.GI10144@duck.suse.cz>
Date:	Wed, 23 Jan 2008 20:41:55 +0100
From:	Jan Kara <jack@...e.cz>
To:	Christoph Hellwig <hch@...radead.org>
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 23-01-08 19:13:06, Christoph Hellwig wrote:
> 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.
  I'm fine with that ;).

> > 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..
  But with which lock you'd like to lock-around i_size update? Note that
you have to make sure you won't race even with read path which currently
doesn't take any locks at all (except for page lock) if I'm right... So,
e.g. NFS, would have to wrap generic_file_aio_read() in some lock to
prevent inode updates while generic_file_aio_read() runs. That doesn't
sound too appealing to me.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/