From: "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
To: Dan Smith <danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org,
Nathan Lynch <ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH] [RFC] c/r: Add UTS support
Date: Thu, 12 Mar 2009 17:48:20 -0500 [thread overview]
Message-ID: <20090312224820.GA12723@hallyn.com> (raw)
In-Reply-To: <87fxhipfrh.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
Quoting Dan Smith (danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org):
> NL> I'd like there to be some discussion about this, because namespace
> NL> creation seems like a significant addition to the semantics of
> NL> restart as I understand it.
>
> Indeed.
>
> NL> Is namespace creation during restart unavoidable, or merely
> NL> desirable? Is there a case for requiring the user to provide a
> NL> suitable namespace environment before attempting restart?
>
> Information about the namespaces has to be saved at checkpoint time no
> matter what, right? I guess I don't see any compelling reason to not
> have the restart operation replicate the environment of the original
> process. Otherwise we require userspace to read and interpret the
> checkpoint stream and selectively feed the bits that the kernel is
> responsible for to the kernel and process the rest itself (or have the
> kernel ignore those records).
Well we haven't yet settled the Oren-vs-Alexey argument of who sets
up the new process tree. Oren would have userspace parse the checkpoint
file, do a bunch of clones to recreate the process tree, then have each
task call sys_restart(). Alexey would have one task call sys_restart()
where the system call then recreates the process tree.
You seem to be doing half of each :) I think if we go with Oren's
route then we should use CLONE_NEWPID etc flags from userspace to set
up the proper relationships. If we go with Alexey's, then the kernel
can just hand-create the nsproxies somewhat the way you are doing using
copy_namespaces().
> What's the argument for depending on userspace to set this up?
Well it forces restart to go through the established userspace API's
when creating resources (in this case, tasks and namespaces) which
means any existing security guarantees are leveraged.
If we go with your patch, we suddenly have to worry about whether
restart is a way to get around the CAP_SYS_ADMIN requirements for
cloning a new namespace. Just as an example.
-serge
next prev parent reply other threads:[~2009-03-12 22:48 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-12 17:56 [PATCH] [RFC] c/r: Add UTS support Dan Smith
[not found] ` <1236880612-15316-1-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-12 21:29 ` Nathan Lynch
2009-03-12 21:56 ` Dan Smith
[not found] ` <87fxhipfrh.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-03-12 22:48 ` Serge E. Hallyn [this message]
[not found] ` <20090312224820.GA12723-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
2009-03-12 22:56 ` Dan Smith
[not found] ` <87bps6pcyf.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-03-13 0:12 ` Serge E. Hallyn
2009-03-18 8:27 ` Oren Laadan
[not found] ` <49C0B069.6060300-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-03-18 9:01 ` Cedric Le Goater
2009-03-18 13:49 ` Serge E. Hallyn
[not found] ` <20090318134932.GC22636-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-18 14:04 ` Dan Smith
[not found] ` <878wn353mf.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-03-18 15:46 ` Cedric Le Goater
[not found] ` <49C1175F.9060600-GANU6spQydw@public.gmane.org>
2009-03-18 15:55 ` Dan Smith
[not found] ` <874oxq6d1x.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-03-18 16:02 ` Cedric Le Goater
2009-03-18 19:50 ` Mike Waychison
[not found] ` <49C1506C.1080500-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2009-03-19 0:10 ` Eric W. Biederman
[not found] ` <m1bprye5io.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-03-19 0:46 ` Mike Waychison
[not found] ` <49C195CF.1080506-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2009-03-19 1:06 ` Eric W. Biederman
[not found] ` <m1ab7icodl.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-03-19 1:51 ` Mike Waychison
[not found] ` <49C1A52D.4000503-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2009-03-19 3:28 ` Eric W. Biederman
[not found] ` <m1iqm6xkc7.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-03-20 17:26 ` Serge E. Hallyn
[not found] ` <20090320172616.GA7203-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-20 19:51 ` Mike Waychison
[not found] ` <49C3F3C0.30100-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2009-03-20 20:40 ` Serge E. Hallyn
2009-03-20 20:53 ` Oren Laadan
2009-03-20 23:26 ` Eric W. Biederman
[not found] ` <m1d4cb3he5.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-03-21 2:38 ` Serge E. Hallyn
[not found] ` <20090321023834.GA21064-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
2009-03-21 3:39 ` Eric W. Biederman
[not found] ` <m1prgbzgqq.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-03-21 14:51 ` Serge E. Hallyn
2009-03-12 22:48 ` Daniel Lezcano
[not found] ` <49B99144.9000106-GANU6spQydw@public.gmane.org>
2009-03-12 22:58 ` Dan Smith
[not found] ` <877i2upcvo.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-03-12 23:11 ` Daniel Lezcano
[not found] ` <49B996BC.1090908-GANU6spQydw@public.gmane.org>
2009-03-12 23:13 ` Dan Smith
[not found] ` <873adipc5l.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
2009-03-12 23:24 ` Daniel Lezcano
[not found] ` <49B999A6.2000005-GANU6spQydw@public.gmane.org>
2009-03-13 15:30 ` Serge E. Hallyn
[not found] ` <20090313153004.GA8317-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-13 15:51 ` Daniel Lezcano
[not found] ` <49BA811C.4070302-GANU6spQydw@public.gmane.org>
2009-03-13 17:15 ` Serge E. Hallyn
[not found] ` <20090313171556.GB10685-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-13 17:53 ` Daniel Lezcano
[not found] ` <49BA9D9C.2030208-GANU6spQydw@public.gmane.org>
2009-03-25 12:01 ` Eric W. Biederman
2009-03-13 15:59 ` Cedric Le Goater
[not found] ` <49BA82CE.4090206-GANU6spQydw@public.gmane.org>
2009-03-13 16:04 ` Daniel Lezcano
2009-03-18 8:32 ` Oren Laadan
2009-03-18 8:35 ` Oren Laadan
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=20090312224820.GA12723@hallyn.com \
--to=serge-a9i7lubdfnhqt0dzr+alfa@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
--cc=ntl-e+AXbWqSrlAAvxtiuMwx3w@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.