linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: William Koh <kkc6196@fb.com>, Andreas Dilger <adilger@dilger.ca>,
	"Theodore Ts'o" <tytso@mit.edu>,
	linux-ext4 <linux-ext4@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Kernel Team <Kernel-team@fb.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] fs: ext4: inode->i_generation not assigned 0.
Date: Thu, 29 Jun 2017 10:35:51 -0400	[thread overview]
Message-ID: <20170629143551.GB1651@fieldses.org> (raw)
In-Reply-To: <20170629045940.GB5865@birch.djwong.org>

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.

--b.

  parent reply	other threads:[~2017-06-29 14:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-28 22:06 [PATCH] fs: ext4: inode->i_generation not assigned 0 Kyungchan Koh
2017-06-29  0:48 ` Darrick J. Wong
2017-06-29  0:58   ` William Koh
2017-06-29  2:32 ` Andreas Dilger
2017-06-29  4:37   ` William Koh
2017-06-29  4:59     ` Darrick J. Wong
2017-06-29 14:28       ` William Koh
2017-06-29 14:35       ` J. Bruce Fields [this message]
2017-06-29 17:25         ` Darrick J. Wong
2017-06-29 18:30           ` J. Bruce Fields
2017-06-29 18:50             ` J. Bruce Fields
2017-07-04  4:04               ` Darrick J. Wong
2017-07-05  1:15                 ` J. Bruce Fields
2017-07-05 19:19                   ` Darrick J. Wong
2017-07-05 20:27                     ` Theodore Ts'o
2017-07-07 10:51                       ` Jeff Layton
2017-07-07 15:51                         ` Theodore Ts'o
2017-07-07 16:13                           ` Jeff Layton
2017-07-07 16:47                             ` J. Bruce Fields
2017-07-05 20:49                     ` J. Bruce Fields
2017-07-06  1:08                       ` NeilBrown
2017-07-06  2:39                         ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170629143551.GB1651@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=Kernel-team@fb.com \
    --cc=adilger@dilger.ca \
    --cc=darrick.wong@oracle.com \
    --cc=kkc6196@fb.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=trond.myklebust@primarydata.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).