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

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

 



On Tue, Dec 6, 2011 at 12:53 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> The trouble is, might very well stop *NOT* at the global root.  Consider
> a race with umount -l; we have no way to tell "it had been outside of
> chroot jail" from "it had walked up to the place where ->mnt_parent had
> been already reset, sorry, no idea what it was".

Sure, but you made that case return NULL already as part of the "no
bastard" case, didn't you?

That part of the patch looked fine.

It was just the extra convolutions around 'bastard' that seemed to be
over-designed, and made for just a single use that seems very
peripheral anyway.

Apart from AppArmor, afaik nobody even really cared where they ended
up, and even AppArmor really didn't want to know - it just had this
totally crazy special case about "/sys".

                 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


[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