[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87oal4e5hu.fsf@x220.int.ebiederm.org>
Date: Thu, 28 May 2015 16:50:37 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Kenton Varda <kenton@...dstorm.io>
Cc: Alexander Larsson <alexl@...hat.com>, gnome-os-list@...me.org,
Linux Containers <containers@...ts.linux-foundation.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>,
James Bottomley <James.Bottomley@...senpartnership.com>,
mclasen@...hat.com, Linux FS Devel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options
Kenton Varda <kenton@...dstorm.io> writes:
> On Thu, May 28, 2015 at 1:06 PM, Alexander Larsson <alexl@...hat.com> wrote:
>> On Thu, 2015-05-28 at 12:14 -0500, Eric W. Biederman wrote:
>>>
>>> > Where does the second namespace enter into this?
>>>
>>> Step a. Create create a user namespace where uid 0 is mapped to your
>>> real uid, and set up your sandbox (aka mount /dev/pts and everything
>>> else).
>>>
>>> Step b. Create a nested user namespace where your uid is identity
>>> mapped and run your desktop application. You can even drop all caps
>>> in
>>> your namespace.
>>
>> Just tried this. Its not the nicest, and it doubles the number of
>> namespaces in action for each sandbox, but it does work.
>
> How much overhead is involved in each user namespace?
sizeof(struct user_namespace).
> Is there any system-wide limit on total namespaces, other than RAM?
There is a system-wide maximum depth, but not count.
> Is there
> (non-negligible) CPU overhead for each syscall seeking permissions in
> the namespace?
ns_capable(ns, X) in some cases can walk up the from a starting user
namespace to the initial user. (The only non-constant operation I am
aware of). However unless the user namespace depth is deep it should
still take a negligible amount of time.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists