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: <20170629172528.GA5869@birch.djwong.org> Date: Thu, 29 Jun 2017 10:25:28 -0700 From: "Darrick J. Wong" <darrick.wong@...cle.com> To: "J. Bruce Fields" <bfields@...ldses.org> Cc: William Koh <kkc6196@...com>, Andreas Dilger <adilger@...ger.ca>, "Theodore Ts'o" <tytso@....edu>, linux-ext4 <linux-ext4@...r.kernel.org>, lkml <linux-kernel@...r.kernel.org>, Kernel Team <Kernel-team@...com>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, Trond Myklebust <trond.myklebust@...marydata.com>, xfs <linux-xfs@...r.kernel.org> Subject: Re: [PATCH] fs: ext4: inode->i_generation not assigned 0. On Thu, Jun 29, 2017 at 10:35:51AM -0400, J. Bruce Fields wrote: > On Wed, Jun 28, 2017 at 09:59:40PM -0700, Darrick J. Wong wrote: > > AFAICT, i_generation == 0 in XFS and btrfs is just as valid as any other > > number. There is no special casing of zero in either filesystem. > > > > So now, my curiosity intrigued, I surveyed all the Linux filesystems > > that can export to NFS. I see that there are actually quite a few fs > > (ext[2-4], exofs, efs, fat, jfs, f2fs, isofs, nilfs2, reiserfs, udf, > > ufs) that treat zero as a special value meaning "ignore generation > > check"; others (xfs, btrfs, fuse, ntfs, ocfs2) that don't consider zero > > special and always require a match; and still others (affs, befs, ceph, > > gfs2, jffs2, squashfs) that don't check at all. > > > > That to mean strongly suggests that more research is necessary to figure > > out why some of the filesystems that support i_generation reserve zero > > as a special value to disable generation checks and why others always > > require an exact match. Until we can recapture why things are they way > > they are, it doesn't make much sense to have a helper that only applies > > to half the filesystems. > > From a quick look at ext2; correct me if I got anything wrong: > > - it looks like this is *only* used by NFS fh->inode lookups, > there's not some other internal use for this special case. > - filehandles are never encoded with i_generation 0, so will > never be returned to clients. > > So, this could only ever be used by an NFS client. But the only NFS > client that could ever use it would be a non-standard client that knew > this special feature of these particular filesystems. > > Sounds like at most a slightly useful tool for malicious clients > attempting filehandle-guessing attacks. > > I'm probably missing something. Was there ever a version of NFS (or more generally callers of the exportfs code) that couldn't deal with i_generation in the file handle, and therefore we invented this generation hack to work around the loss of the generation information? There's a comment in xfs_fs_encode_fh about not supporting 64bit inodes with subtree_check (which seems to require one ino/gen pair for the file and a second pair for the file's parent) on NFSv2 because v2 doesn't provide enough space for all the file handle information, but that's the furthest I got with lazy-mining the git history. :) --D > > --b.
Powered by blists - more mailing lists