From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [git pull] apparmor fix for __d_path() misuse
Date: Wed, 7 Dec 2011 16:32:53 +0000
Message-ID: <20111207163253.GD2203@ZenIV.linux.org.uk>
References: <CA+55aFyaz7K4V5xLmaQ9GK=5LA1mbRdVGCFspET=y6ode_i=jg@mail.gmail.com>
 <20111207011047.GQ2203@ZenIV.linux.org.uk>
 <20111207013720.GS2203@ZenIV.linux.org.uk>
 <201112070326.pB73QPZo042162@www262.sakura.ne.jp>
 <20111207034238.GX2203@ZenIV.linux.org.uk>
 <201112070501.pB751LoP064331@www262.sakura.ne.jp>
 <20111207051908.GA2203@ZenIV.linux.org.uk>
 <201112070544.pB75iX12072157@www262.sakura.ne.jp>
 <20111207065437.GB2203@ZenIV.linux.org.uk>
 <201112070859.pB78xn7x007845@www262.sakura.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: john.johansen@canonical.com, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, torvalds@linux-foundation.org
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <201112070859.pB78xn7x007845@www262.sakura.ne.jp>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Wed, Dec 07, 2011 at 05:59:49PM +0900, Tetsuo Handa wrote:
> Al Viro wrote:
> > BTW, what your current code does if you have a file bound on another
> > file, open it, umount -l it, let the dust settle and then do some operation
> > that triggers tomoyo_get_absolute_path() on it?  Because you'll be getting
> > a vfsmount/dentry pair that has
> > 	* dentry == vfsmount->mnt_root
> > 	* vfsmount->mnt_parent == vfsmount
> > 	* dentry->d_inode being a non-directory
> > and there is nothing whatsoever in what remains of the pathname.  Not a single
> > component.  IOW, you'll get "/" in buf.  Might be good in a testsuite - is
> > there any code in security/tomoyo that would be relying on assumption that
> > only directory might have a name entirely without components?
> 
> TOMOYO assumes that only directory ends with '/'.

Then it's broken in the current mainline (and had been for as long as it
had been using __d_path()).  Because that's all you'll get from it
for such vfsmount/dentry pair...

> Among above three results, the last one will be the best.

OK, I'm fine with your patch; for bisectability sake it ought to go before
mine, with mine on top of it.

How will we do that?  Should I put it into vfs.git#for-linus before __d_path()
patch and ask Linus to pull that?