Matt Helsley wrote:

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.

quoted

if I'm root, and I want to checkpoint, and later restart, my sshd server
(assuming we support listening sockets) - then why not ?
we can just let it be, and have the restart fail (if it isn't root that
does the restart); perhaps add something like warn_checkpoint() (similar
to deny, but only warns) ?

	How will folks not specializing in checkpoint/restart know when to use
this as opposed to deny?

	Instead, how about a flag to sys_checkpoint() -- DO_RISKY_CHECKPOINT --
which checkpoints despite !may_checkpoint?

I also agree with Matt - so we have a quorum :)

so just to clarify: sys_checkpoint() is to fail (with what error ?) if the
deny-checkpoint test fails.

however, if the user is risky, she can specify CR_CHECKPOINT_RISKY to force
an attempt to checkpoint as is.

does this sound right ?

Oren.