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
| ||
|
Message-ID: <20130213134033.GF14195@fieldses.org> Date: Wed, 13 Feb 2013 08:40:33 -0500 From: "J. Bruce Fields" <bfields@...ldses.org> To: Andreas Dilger <adilger@...ger.ca> Cc: linux-ext4@...r.kernel.org, sandeen@...hat.com, Theodore Ts'o <tytso@....edu>, Bernd Schubert <bernd.schubert@...m.fraunhofer.de>, gluster-devel@...gnu.org Subject: Re: regressions due to 64-bit ext4 directory cookies On Tue, Feb 12, 2013 at 10:56:36PM -0800, Andreas Dilger wrote: > On 2013-02-12, at 12:28 PM, J. Bruce Fields wrote: > > 06effdbb49af5f6c "nfsd: vfs_llseek() with 32 or 64 bit offsets (hashes)" > > and previous patches solved problems with hash collisions in large > > directories by using 64- instead of 32- bit directory hashes in some > > cases. But it caused problems for users who assume directory offsets > > are "small". Two cases we've run across: > > > > - older NFS clients: 64-bit cookies cause applications on > > many older clients to fail. > > - gluster: gluster assumed that it could take the top bits of > > the offset for its own use. > > > > In both cases we could argue we're in the right: the nfs protocol > > defines cookies to be 64 bits, so clients should be prepared to handle them (remapping to smaller integers if necessary to placate > > applications using older system interfaces). > > There appears to already be support for handling this for NFSv2 > clients, so it should be possible to have an NFS server mount > option to set this for all clients: > > /* NFSv2 only supports 32 bit cookies */ > if (rqstp->rq_vers > 2) > may_flags |= NFSD_MAY_64BIT_COOKIE; > > Alternately, this might be detected on a per-client basis by > whitelist or blacklist if there is some way for the server to > identify the client? No, there isn't. --b. -- 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
Powered by blists - more mailing lists