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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 22 Feb 2017 12:53:47 +0100
From:   Alexey Gladkov <gladkov.alexey@...il.com>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Vasiliy Kulikov <segoon@...nwall.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Pavel Emelyanov <xemul@...allels.com>
Subject: Re: [PATCH] Add pidfs filesystem

On Tue, Feb 21, 2017 at 03:57:47PM +0100, Oleg Nesterov wrote:
> On 02/18, Alexey Gladkov wrote:
> >
> > This patch allows to mount only the part of /proc related to pids
> > without rest objects. Since this is an addon to /proc, flags applied to
> > /proc have an effect on this pidfs filesystem.
> 
> I leave this to you and Eric, but imo it would be nice to avoid another
> filesystem.
> 
> > Why not implement it as another flag to /proc ?
> >
> > The /proc flags is stored in the pid_namespace and are global for
> > namespace. It means that if you add a flag to hide all except the pids,
> > then it will act on all mounted instances of /proc.
> 
> But perhaps we can use mnt_flags? For example, lets abuse MNT_NODEV, see
> the simple patch below. Not sure it is correct/complete, just to illustrate
> the idea.
> 
> With this patch you can mount proc with -onodev and it will only show
> pids/self/thread_self:
> 
> 	# mkdir /tmp/D
> 	# mount -t proc -o nodev none /tmp/D
> 	# ls /tmp/D
> 	1   11	13  15	17  19	20  22	24  28	3   31	33  4  56  7  9     thread-self
> 	10  12	14  16	18  2	21  23	27  29	30  32	34  5  6   8  self
> 	# cat /tmp/D/meminfo
> 	cat: /tmp/D/meminfo: No such file or directory
> 	# ls /tmp/D/irq
> 	ls: cannot open directory /tmp/D/irq: No such file or directory
> 
> No?

I'm embarrassed that we start the change procfs by abuse something. It is very
difficult to explain why this option leads to such consequences on procfs.

Also with this change it won't be the same procfs. We can't to name it as procfs
because procfs have cpuinfo, meminfo, etc.

What do you think about this ?

-- 
Rgrds, legion

Powered by blists - more mailing lists