From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934365AbdC3Vgr (ORCPT ); Thu, 30 Mar 2017 17:36:47 -0400 Received: from mozilla-myt-1.haze.yandex.net ([77.88.23.115]:43840 "EHLO mail.unsafe.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933392AbdC3Vgq (ORCPT ); Thu, 30 Mar 2017 17:36:46 -0400 Date: Thu, 30 Mar 2017 23:45:23 +0200 From: Alexey Gladkov To: Djalal Harouni Cc: Linux Kernel Mailing List , Linux API , "Kirill A. Shutemov" , Vasiliy Kulikov , Al Viro , "Eric W. Biederman" , Oleg Nesterov , Pavel Emelyanov , James Bottomley , "Dmitry V. Levin" , Jann Horn , Kees Cook , Andy Lutomirski , Miklos Szeredi Subject: Re: [RFC] Add option to mount only a pids subset Message-ID: <20170330214523.GA13761@comp-core-i7-2640m-0182e6> References: <20170312021257.GP29622@ZenIV.linux.org.uk> <20170320125855.GG4554@comp-core-i7-2640m-0182e6> <20170323220712.GH4554@comp-core-i7-2640m-0182e6> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 26, 2017 at 09:03:33AM +0200, Djalal Harouni wrote: > (Cc'ed Kees and Jann for the procfs stacking issue) > > > I completely agree with you that it looks wrong when options of one > > mountpoint affect the others mountpoints. > > > >> I'm not sure if that's the right approach, it is still buggy, however > >> seems that your patch also stores the mount option inside the > >> pid_namespace which may get propagated to all mounts inside same pidns > >> ? > > > > I don't store 'pidonly' option in my current patch. I mean in: > > https://lkml.org/lkml/2017/3/20/363 > > > > I parse options twice at first mount of procfs. It happens before > > the mounting /proc in userspace. > > > > I know it's bad, but I couldn't find place to store this option. > > Ok, then maybe that approach of having a procfs struct holder instead > of using pid namespace may help! I deside to stop doing my patch. I talked with a few people and found out that the overlayfs doesn't feel very well if on the lower level filesystem appear/disappear files. In addition with the pidfs isn't so simple. Separate the root will lead to a doubling of memory consumption and restrictions on the filesystem operations level can easily be skipped. It means that even I can do this pidfs (or pid subset in /proc), it will be pointless. -- Rgrds, legion From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Gladkov Subject: Re: [RFC] Add option to mount only a pids subset Date: Thu, 30 Mar 2017 23:45:23 +0200 Message-ID: <20170330214523.GA13761@comp-core-i7-2640m-0182e6> References: <20170312021257.GP29622@ZenIV.linux.org.uk> <20170320125855.GG4554@comp-core-i7-2640m-0182e6> <20170323220712.GH4554@comp-core-i7-2640m-0182e6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Djalal Harouni Cc: Linux Kernel Mailing List , Linux API , "Kirill A. Shutemov" , Vasiliy Kulikov , Al Viro , "Eric W. Biederman" , Oleg Nesterov , Pavel Emelyanov , James Bottomley , "Dmitry V. Levin" , Jann Horn , Kees Cook , Andy Lutomirski , Miklos Szeredi List-Id: linux-api@vger.kernel.org On Sun, Mar 26, 2017 at 09:03:33AM +0200, Djalal Harouni wrote: > (Cc'ed Kees and Jann for the procfs stacking issue) > > > I completely agree with you that it looks wrong when options of one > > mountpoint affect the others mountpoints. > > > >> I'm not sure if that's the right approach, it is still buggy, however > >> seems that your patch also stores the mount option inside the > >> pid_namespace which may get propagated to all mounts inside same pidns > >> ? > > > > I don't store 'pidonly' option in my current patch. I mean in: > > https://lkml.org/lkml/2017/3/20/363 > > > > I parse options twice at first mount of procfs. It happens before > > the mounting /proc in userspace. > > > > I know it's bad, but I couldn't find place to store this option. > > Ok, then maybe that approach of having a procfs struct holder instead > of using pid namespace may help! I deside to stop doing my patch. I talked with a few people and found out that the overlayfs doesn't feel very well if on the lower level filesystem appear/disappear files. In addition with the pidfs isn't so simple. Separate the root will lead to a doubling of memory consumption and restrictions on the filesystem operations level can easily be skipped. It means that even I can do this pidfs (or pid subset in /proc), it will be pointless. -- Rgrds, legion