Re: [RFC v7][PATCH 2/9] General infrastructure for checkpoint restart

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Matt Helsley (matthltc@us.ibm.com):
> On Mon, 2008-10-27 at 13:11 -0400, Oren Laadan wrote:
> > Dave Hansen wrote:
> > > On Mon, 2008-10-27 at 07:03 -0400, Oren Laadan wrote:
> > >>> In our implementation, we simply refused to checkpoint setid
> > >> programs.
> > >>
> > >> True. And this works very well for HPC applications.
> > >>
> > >> However, it doesn't work so well for server applications, for
> > >> instance.
> > >>
> > >> Also, you could use file system snapshotting to ensure that the file
> > >> system view does not change, and still face the same issue.
> > >>
> > >> So I'm perfectly ok with deferring this discussion to a later time :)
> > > 
> > > Oren, is this a good place to stick a process_deny_checkpoint()?  Both
> > > so we refuse to checkpoint, and document this as something that has to
> > > be addressed later?
> > 
> > why refuse to checkpoint ?
> 
> 	If most setuid programs hold privileged resources for extended periods
> of time after dropping privileges then it seems like a good idea to
> refuse to checkpoint. Restart of those programs would be quite
> unreliable unless/until we find a nice solution.

I agree with Dave and Matt.  Let's assume that we have a setuid root
program which creates some resources then drops to username kooky.  If
you now checkpoint and restart that program, then a stupid restart will
either

	1. be done as user kooky and not be able to recreate the
	resources, fail.
	2. be done as user root and not drop uid back to kooky, unsafe.

For the earliest prototypes of c/r, I think saying that setuid an the
life of a container makes checkpoint impossible is the right thing to
do.

-serge

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>