Quoting Matt Helsley (matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org):

On Mon, 2008-10-27 at 13:11 -0400, Oren Laadan wrote:

quoted

Dave Hansen wrote:

quoted

On Mon, 2008-10-27 at 07:03 -0400, Oren Laadan wrote:

quoted

quoted

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 from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html