[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0903131018390.3940@localhost.localdomain>
Date: Fri, 13 Mar 2009 10:27:54 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
cc: Ying Han <yinghan@...gle.com>,
"Serge E. Hallyn" <serue@...ibm.com>, linux-api@...r.kernel.org,
containers@...ts.linux-foundation.org, hpa@...or.com,
linux-kernel@...r.kernel.org,
Dave Hansen <dave@...ux.vnet.ibm.com>, linux-mm@...ck.org,
viro@...iv.linux.org.uk, mingo@...e.hu, mpm@...enic.com,
Andrew Morton <akpm@...ux-foundation.org>, xemul@...nvz.org,
tglx@...utronix.de, Alexey Dobriyan <adobriyan@...il.com>
Subject: Re: How much of a mess does OpenVZ make? ;) Was: What can OpenVZ
do?
On Thu, 12 Mar 2009, Sukadev Bhattiprolu wrote:
> Ying Han [yinghan@...gle.com] wrote:
> | Hi Serge:
> | I made a patch based on Oren's tree recently which implement a new
> | syscall clone_with_pid. I tested with checkpoint/restart process tree
> | and it works as expected.
>
> Yes, I think we had a version of clone() with pid a while ago.
Are people _at_all_ thinking about security?
Obviously not.
There's no way we can do anything like this. Sure, it's trivial to do
inside the kernel. But it also sounds like a _wonderful_ attack vector
against badly written user-land software that sends signals and has small
races.
Quite frankly, from having followed the discussion(s) over the last few
weeks about checkpoint/restart in various forms, my reaction to just about
_all_ of this is that people pushing this are pretty damn borderline.
I think you guys are working on all the wrong problems.
Let's face it, we're not going to _ever_ checkpoint any kind of general
case process. Just TCP makes that fundamentally impossible in the general
case, and there are lots and lots of other cases too (just something as
totally _trivial_ as all the files in the filesystem that don't get rolled
back).
So unless people start realizing that
(a) processes that want to be checkpointed had better be ready and aware
of it, and help out
(b) there's no way in hell that we're going to add these kinds of
interfaces that have dubious upsides (just teach the damn program
you're checkpointing that pids will change, and admit to everybody
that people who want to be checkpointed need to do work) and are
potential security holes.
(c) if you are going to play any deeper games, you need to have
privileges. IOW, "clone_with_pid()" is ok for _root_, but not for
some random user. And you'd better keep that in mind EVERY SINGLE
STEP OF THE WAY.
I'm really fed up with these discussions. I have seen almost _zero_
critical thinking at all. Probably because anybody who is in the least
doubtful about it simply has tuned out the discussion. So here's my input:
start small, start over, and start thinking about other issues than just
checkpointing.
Linus
--
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