[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87shuk62so.fsf@x220.int.ebiederm.org>
Date: Thu, 04 Aug 2016 09:12:39 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Hari Bathini <hbathini@...ux.vnet.ibm.com>
Cc: daniel@...earbox.net, peterz@...radead.org,
linux-kernel@...r.kernel.org, acme@...nel.org,
alexander.shishkin@...ux.intel.com, mingo@...hat.com,
paulus@...ba.org, kernel@...p.com, rostedt@...dmis.org,
viro@...iv.linux.org.uk, aravinda@...ux.vnet.ibm.com,
ananth@...ibm.com
Subject: Re: [RFC PATCH v2 3/3] tracefs: add 'newinstance' mount option
Hari Bathini <hbathini@...ux.vnet.ibm.com> writes:
> Hi Eric,
>
>
> Thanks for the comments..
>
>
> On Thursday 04 August 2016 08:24 AM, Eric W. Biederman wrote:
>> Hari Bathini <hbathini@...ux.vnet.ibm.com> writes:
>>
>>> When tracefs is mounted inside a container, its files are visible to
>>> all containers. This implies that a user from within a container can
>>> list/delete uprobes registered elsewhere, leading to security issues
>>> and/or denial of service (Eg. deleting a probe that is registered from
>>> elsewhere). This patch addresses this problem by adding mount option
>>> 'newinstance', allowing containers to have their own instance mounted
>>> separately. Something like the below from within a container:
>> newinstance is an anti-pattern in devpts and should not be copied.
>> To fix some severe defects of devpts we had to always create new
>> istances and the code and the testing to make that all work was
>
> OK..
>
>> not pleasant. Please don't add another option that we will just have to
>> make redundant later.
>
> IIUC, you mean, implicitly create a new instance for tracefs mount
> inside container without the need for a new option?
Yes. Or always create a new instance. Whatever makes sense. If we
don't have to bind things to a namespace all the better.
Eric
Powered by blists - more mailing lists