| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <519F2F65.4000400@cn.fujitsu.com> Date: Fri, 24 May 2013 17:14:13 +0800 From: Gu Zheng <guz.fnst@...fujitsu.com> To: Stephen Mell <sub.atomic.fusion@...il.com> CC: linux-kernel@...r.kernel.org Subject: Re: [PATCH] proc: move proc mount options out of pid_namespace Hi Stephen, On 05/24/2013 12:29 PM, Stephen Mell wrote: > Gu, > > On Friday, May 24, 2013 11:03:31 Gu Zheng wrote: >> Hi Stephen, >> >> On 05/24/2013 07:32 AM, Stephen Mell wrote: >> >>> On Thursday, May 23, 2013 18:20:57 Gu Zheng wrote: >>> >>>> Here it'll create a new proc sb instance which holds the same context as the old ones >>>> each time we mount proc though in the same PID namespace, won't it? >>> I believe so. But this is the point, right? > >> Yes, but I think it's also the problem. >> >>> They won't be identical if different mount options are used, I don't think. >> >> If different mount options are used, we'll create different super block instance, and they have >> the same context, only the difference is each one holds different proc_sb_info. >> But I think what we really want is only one proc sb instance and create different proc_sb_info >> if different mount options are used. > > Will having several different superblocks cause problems, or is it merely inefficient? Not only inefficient. >I freely admit to not really knowing what I'm doing, and I thank you for your assistance. > How is this situation distinct from that of ramfs? It appears to have a superblock for each mount. They're different, each ramfs uses a split superblock to manage it's infos, e.g. the usage, and each ramfs mount instance should not affect others. But proc is a common interface, each mount instance holds the same context, so there's no need to create a new superblock instance each time mount if we in the same PID namespace. > It would seem to me as though one cannot have different sb_infos with the same superblock, making storing the mount options in sb_info effectively the same as storing them in the superblock itself, for the purposes of this discussion. Where would the mount options be stored, if not in the superblock? > One fuzzy way in my mind, I'm not sure whether it's OK, but we can discuss it. Split hide_pid, pid_gid, and proc_self from pid_namespace, and create struct proc_sb_info(maybe the name "proc_mount_info" is better). And create a new list domain in the pid_namespace to contain the proc_sb_info instances. Each time we mount proc in a new directory only create a new proc_sb_info instance, and added it to the list in pid_namespace. But this leads to another problem, how to get the right proc_sb_info instance in proc permission checking routine, do you have any idea? what do you think of this way? Thanks, Gu >>> >>>> Here the pre-check seems needless. >>> Is that new with my patch, or has it always been needless? >> >> Yeah, it's always needless. >> >> Thanks, >> Gu >> >>> >>> Thanks, >>> Stephen > > Thanks again, > Stephen > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists