From: Cedric Le Goater <clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
To: Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Cc: Linux Containers
<containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
"Eric W. Biederman"
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Subject: Re: namespaces compatibility list
Date: Tue, 06 Nov 2007 17:46:09 +0100 [thread overview]
Message-ID: <47309A51.1050607@fr.ibm.com> (raw)
In-Reply-To: <473091F9.10406-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Pavel Emelyanov wrote:
> Cedric Le Goater wrote:
>> Pavel Emelyanov wrote:
>>> Cedric Le Goater wrote:
>>>> Pavel Emelyanov wrote:
>>>>> Hi guys!
>>>>>
>>>>> As you might have seen, recently there was some spontaneous
>>>>> discussion about the namespaces-working-together problems.
>>>>>
>>>>> Ted T'so proposed to create some document that describes what
>>>>> problems user may have when he/she creates some new namespace,
>>>>> but keeps others shared. I like this idea, so here's the draft
>>>>> with the problems I currently have in mind and can describe
>>>>> somewhat audibly - the "namespaces compatibility list".
>>>> that compatibility list could be encoded in the way we check
>>>> the clone flags in copy_process() and unshare(). It would
>>>> also be good to have it as a comment somewhere in kernel/fork.c
>>> How can we insure, that a new task will not share the files
>>> with its parent to address the PID namespaces vs VFS namespaces
>>> interaction? There's no way to do it. We can only keep them in
>>> one IPC namespace...
>> ? I'm not sure I understand you.
>
> As far as I understand, you propose the check for the clone flags
> in the copy_process()/sys_unshare() and return -EINVAL for the cases
> we consider to be unsafe. E.g. when a user wants to clone new pid
> namespace, he must clone the ipc namespace as well.
yes.
> But my point is that this check is not enough - user may kill himself
> by cloning a pid namespace and sharing the pids via the filesystem
> (like with the example with futexes) and there's no way to check for
> this situation in the copy_process()/sys_unchare.
right. I think we can address Ulrich concerns first because we have
a solution for it (which looks like unsharing all namespaces at once,
here comes back the container object story :)
> I mean that this list cannot be encoded. But we can warn user, that
> some stuff will stop working if he violates some rules.
and then do that for the futexes, which are a real difficult case.
thanks,
C.
next prev parent reply other threads:[~2007-11-06 16:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-06 10:51 namespaces compatibility list Pavel Emelyanov
[not found] ` <47304729.8000309-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2007-11-06 12:36 ` Kirill Korotaev
2007-11-06 12:54 ` Cedric Le Goater
[not found] ` <4730640D.9030407-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2007-11-06 13:00 ` Pavel Emelyanov
[not found] ` <4730655C.8000306-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2007-11-06 16:01 ` Cedric Le Goater
[not found] ` <47308FDB.4010302-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2007-11-06 16:10 ` Pavel Emelyanov
[not found] ` <473091F9.10406-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2007-11-06 16:46 ` Cedric Le Goater [this message]
[not found] ` <47309A51.1050607-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2007-11-06 17:00 ` Eric W. Biederman
[not found] ` <m1ejf371hw.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org>
2007-11-06 17:09 ` Pavel Emelyanov
[not found] ` <47309FAD.90702-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2007-11-06 17:46 ` Eric W. Biederman
2007-11-07 8:20 ` Cedric Le Goater
[not found] ` <4731756A.3060701-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2007-11-07 9:29 ` Pavel Emelyanov
2007-11-07 8:14 ` Cedric Le Goater
2007-11-06 16:36 ` Eric W. Biederman
[not found] ` <m1ode772lx.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org>
2007-11-06 16:48 ` Cedric Le Goater
2007-11-07 13:49 ` Cedric Le Goater
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47309A51.1050607@fr.ibm.com \
--to=clg-nmtc/0zbporqt0dzr+alfa@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.