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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 12 May 2011 14:52:04 -0400
From:	Trond Myklebust <Trond.Myklebust@...app.com>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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, 2011-05-12 at 18:40 +0100, Al Viro wrote:
> 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.

Sure. I don't care about nameidata in itself. I care about knowing when
it is appropriate to do just a lookup, when to do an atomic open or
create+open. lookup_one_len() only works for the lookup case.

My point is rather that AFAICS ecryptfs needs a different VFS helper so
that it can request 'lookup+open this component' or 'create+open this
component'. It shouldn't have to care about the details of how the
underlying filesystem works (whether that filesystem uses intents, your
new atomic open interface or does separate lookup+create+open calls).

It may also need to call follow_managed(). Again, if that is the case,
then we would need a VFS helper.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com

--
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/