linux-kernel - Re: [PATCH] Add pidfs filesystem

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