linux-kernel - Re: [PATCH v2] locks: Filter /proc/locks output on proc pid ns

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8760rhiwlw.fsf@x220.int.ebiederm.org>
Date:	Wed, 03 Aug 2016 12:35:39 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Nikolay Borisov <kernel@...p.com>
Cc:	"J. Bruce Fields" <bfields@...ldses.org>,
	Pavel Emelyanov <xemul@...tuozzo.com>,
	Jeff Layton <jlayton@...chiereds.net>,
	Andrey Vagin <avagin@...nvz.org>,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	viro@...iv.linux.org.uk
Subject: Re: [PATCH v2] locks: Filter /proc/locks output on proc pid ns

Nikolay Borisov <kernel@...p.com> writes:

> On 08/03/2016 06:06 PM, J. Bruce Fields wrote:
>> Digging around...  Oh, I see, there's an optional 'lock:..' line in
>> /proc/[pid]/fdinfo/[pid] file, is that what you're looking at?  I'd
>> forgotten.  Yeah, maybe that would make more sense long term.
>
> Yep, that's the one but this requires the userspace to be updated to use
> that interface. In the meantime we could do away with some maintenance
> of the existing /proc/locks :)

I am tempted to say let's not change /proc/locks at all, but if locks
really are in a pid namespace than I do think it makes sense to filter
them in /proc just so there is not excessive visiblity outside of the
pid namespace.

Excessive visibility is a problem on it's own.

Eric