On Tue, Dec 6, 2011 at 7:48 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> Fix for use-after-free race in apparmor d_namespace_path() and
> partially sanitizing the atrocious __d_path() API that has caused that
> mess in the first place.
Ugh, having looked at this, I really don't want to pull it.
First off, I do agree that the __d_path() api isn't pleasant, and that
we can/should change it. I just don't agree with the particular
changes. Feel free to try to convince me otherwise, but..
As far as I can tell, the *only* user of the new 'bastard' interface
is (apart from the pure amusement for the name) that silly special
check for AppArmour.
Is AA *worth* that special case? Does it even care that deeply?
So my argument is that I think your change to make 'root' const an
dnot be changed is good, and should stay. But 'bastard' should just go
away, amusingly named or not. All sane callers already call it with a
NULL pointer. The one case that doesn't isn't worth worrying about,
and should strive to solve its problems some saner way.
John explicitly cc'd, since he's the one that would have to figure out
that /sys special case. Is it possible that just calling __d_path()
with the global system root would be sufficient for apparmor in this
case to figure out the /sys part?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
