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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 06, 2011 at 06:02:22PM -0800, Linus Torvalds wrote:
> You are the only one who seems to think that it matters. No code
> agrees with you except for the clearly broken AppArmor code that
> everybody agrees should just go the f*ck away.
> 
> > See what I'm talking about? ?I'm fine with giving the pathname to global
> > root. ?It's doing that to *random* just-unmounted vfsmount that is not
> > a good thing.
> 
> It *never* matters. The pathname should never be used at all.
> 
> We want to *see* what the pathname is, but no code should ever use it.
> 
> The *only* valid use for the broken pathname is for a "show user debug
> information". That's all I've ever claimed. The "where it was mounted
> - or *if* it was mounted" part is pointless.

Sigh...  OK, let's leave that.  I'm not saying that any code uses that
information - in fact, if you look at the last patch I've posted, nothing
(including apparmor) does.  I have a problem with wildly racy debug info
randomly intermixed with reliable one, but in the end it doesn't matter.

Could you look at that patch and comment on it, on its merits alone?
What's done there:
	* prepend_path() root argument becomes const.  I think everyone
agrees with that.
	* __d_path() is never called with NULL/NULL root.  It was a kludge
to start with.  Instead, we have an explicit function - d_absolute_root().
Same as __d_path(), except that it doesn't get root passed and stops where
it stops.  apparmor and tomoyo are using it.
	* __d_path() returns NULL on path outside of root.  The main
caller is show_mountinfo() and that's precisely what we pass root for - to
skip those outside chroot jail.  Those who don't want that can (and do)
use d_path().
	* __d_path() root argument becomes const.  Everyone agrees, I hope.
	* apparmor does *NOT* try to use __d_path() or any of its variants
when it sees that path->mnt is an internal vfsmount.  In that case it's
definitely not mounted anywhere and dentry_path() is exactly what we want
there.  Handling of sysctl()-triggered weirdness is moved to that place.
	* if apparmor is asked to do pathname relative to chroot jail
and __d_path() tells it we it's not in that jail, the sucker just calls
d_absolute_path() instead.  That's the other remaining caller of __d_path(),
BTW.

Are you OK with the above?
--
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


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux