Re: [git pull] apparmor fix for __d_path() misuse

[Al Viro]

On Tue, Dec 06, 2011 at 04:42:00PM -0800, Linus Torvalds wrote:

> This part is still just pure and utter sh*t.
> 
> You have not explained why that information is *ever* valid. And I
> claim it isn't.
> 
> We have a bug in our current __d_path(). And I claim that the
> underlying cause of the bug is the crazy "let's return this
> nonsensical and idiotic information that cannot possibly make sense to
> anybody".
> 
> We shouldn't have done that in the first place. And we certainly
> shouldn't *continue* doing that.

Sigh...  This is what it boils down to: there are 3 very different cases -
we'd walked to a global root, we'd raced with umount and we are someplace
never mounted at all.  Case 1 is fine; if apparmor cares whose namespace
it is, it can bloody well check path->mnt itself.  Case 2 is one where
I think that returning pathname does more damage than good; it's really
random in that case and returning NULL is the best thing we can do.
So far, so good, and we don't need to return *any* references to vfsmounts.

Unfortunately, there's also case 3.  Internal vfsmounts.  And that's where
it hits the fan.  Oh, wait...

Guys, I think I know how to deal with that crap.  We *CAN* recognize
internal vfsmounts just fine.  It's right there in ->mnt_flags.  And
in that case bothering with __d_path() and correcting it post-factum is
just plain wrong.

So let's add d_absolute_path(path, buf, buflen).  Having it check that
we'd walked to something mounted.  And returning NULL otherwise.  _Never_
mangle the pathname; replace that procfs weirdness in apparmor with
"Is our path on internal vfsmount?  If so, use dentry_path() on dentry
part and slap /proc/ in front if it was procfs" and that's it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/