Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options
- From: Andy Lutomirski <luto amacapital net>
- To: Alexander Larsson <alexl redhat com>
- Cc: gnome-os-list gnome org, Linux Containers <containers lists linux-foundation org>, "linux-kernel vger kernel org" <linux-kernel vger kernel org>, James Bottomley <James Bottomley hansenpartnership com>, mclasen redhat com, "Eric W. Biederman" <ebiederm xmission com>, Linux FS Devel <linux-fsdevel vger kernel org>
- Subject: Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options
- Date: Tue, 8 Mar 2016 10:17:56 -0800
On Tue, Mar 8, 2016 at 1:16 AM, Alexander Larsson <alexl redhat com> wrote:
On mån, 2016-03-07 at 20:59 -0800, Andy Lutomirski wrote:
On Thu, May 28, 2015 at 12:42 PM, Eric W. Biederman
<ebiederm xmission com> wrote:
Andy Lutomirski <luto amacapital net> writes:
Apparently alexl is encountering some annoyances related to the
current workaround, and the workaround is certainly ugly.
It works, but it introduces an extra namespace that gets exposed to the
world, which is pretty ugly. For instance, entering the namespace
becomes hard. I can setns() into the intermediate user+mount namespace
without problems, but if i try to setns into the final user+mount ns
(it gets its own implicit mount ns) i get EPERM. I'm not sure exactly
why though...
Your proposal seems like it could break some use cases involving
fscaps on a mount or mount-like binary.
What if we change it to use the owner of the userns that owns the
current mount ns? For anything that doesn't explicitly use
namespaces, this will be zero. For namespace users, it should do the
right thing.
Any of these is fine with me. One nice thing would if i could somehow
detect whether this was supported or not so that i can fall back on the
old workaround.
I'll send a patch.
I suppose the straightforward, if slightly awkward, way to detect it
is just to try it -- create a namespace and try to mount devpts.
--Andy
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]