linux-kernel - Re: [patch 01/10] vfs: add path_create() and path

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080403005836.GT9785@ZenIV.linux.org.uk>
Date:	Thu, 3 Apr 2008 01:58:37 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Trond Myklebust <trond.myklebust@....uio.no>
Cc:	Miklos Szeredi <miklos@...redi.hu>, akpm@...ux-foundation.org,
	dave@...ux.vnet.ibm.com, ezk@...sunysb.edu,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 01/10] vfs: add path_create() and path_mknod()

On Wed, Apr 02, 2008 at 08:42:09PM -0400, Trond Myklebust wrote:

> > At the very least, you want "that thing is still busy" on normal umount -
> > we are still in the middle of write(2) and hell knows how long it's going
> > to last.  So you need to play with refcount of vfsmount in a very nasty
> > way, for all your pains. 
> 
> We already call fget_light()/fput_light() around the whole call to
> vfs_write(). Substituting a call to something which takes a reference to
> the new structure is trivial.

Huh?  So you want an extra layer of indirection?  descriptor table -> that
one -> struct file?  And refcounting these puppies?
 
> It allows you to get rid of the vfsmount 'argument' when opening a file,
> which again lowers the barrier for stacking filesystems.

I don't see how that would fix the fundamental breakage in those, but
anyway... (and yes, ecryptfs has interesting issues, but the look of it).

> As far as the filesystems themselves are concerned, the effect is to
> enforce your assertion that file operations should not depend on the
> namespace.

I really doubt that it's worth doing in this area...  "Don't use ->f_vfsmnt
in fs code" is easily enforced and struct file is really used outside of
filesystem code in fs-independent ways.

IOW, I don't believe that it's worth introducing a new layer between descriptor
table and files.  BTW, that'll complicate union-mount handling (real ones, not
unionfs under different name) and quite a few other things...
--
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/