linux-kernel - Re: [GIT PULL] fuse fix for 2.6.39

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: <20110512174029.GB19987@ZenIV.linux.org.uk>
Date:	Thu, 12 May 2011 18:40:30 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Trond Myklebust <Trond.Myklebust@...app.com>,
	Miklos Szeredi <miklos@...redi.hu>,
	Christoph Hellwig <hch@....de>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [GIT PULL] fuse fix for 2.6.39

On Thu, May 12, 2011 at 10:21:21AM -0700, Linus Torvalds wrote:
> On Thu, May 12, 2011 at 9:28 AM, Trond Myklebust
> <Trond.Myklebust@...app.com> wrote:
> >
> > NFS also requires look up using the full 'struct path' if/when we happen
> > upon an automount point (i.e. if we cross into a submounted filesystem
> > on the server or if we encounter an NFSv4 referral). Again, this is
> > something that lookup_one_len() can't do.
> 
> Sure. But we might not want to oops. Would you be willing to try
> ecryptfs over NFS to at least make it limp along?

IMO that's crap; not the part about not wanting an oops, but lookup_one_len()
one.  We do *NOT* want to pass nameidata all over the place; that had been
a mistake in the first place.  Proper solution will have to wait one more
cycle, but it's going to be along the lines of "pass struct file * explicitly
on the last component handling; screw nameidata for everything else for old
methods".  We already have the call sites (almost) separated in namei.c and
I'm going to finish that come the next cycle.  Again, the long-term solution
will have ->d_revalidate() and ->lookup() *lose* struct nameidata * argument,
with new method used in place of ->open() for the last component.  Defaulting
to the current sequence, yes, but NFS will be a lot more comfortable using
it instead of the Cthulhu-scaring kludges it relies upon now.  At the same
point ecryptfs will have one more method to pass through to the underlying
fs.  And nameidata will be passed only to ->follow_link(), where it's
inevitable.  I hoped to do (and debug) that during the last cycle, but
do_last() got mutilated by Nick's patchset and during this cycle I was
MIA completely.  Sorry, but that'll have to wait until .40 ;-/

Again, lookup_one_len() (and not having nameidata anywhere in sight) is
right and proper.
--
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/