> Quoting Oren Laadan (
orenl@cs.columbia.edu):
>>
>> Serge E. Hallyn wrote:
>>> Quoting Oren Laadan (
orenl@cs.columbia.edu):
>>> Just thinking aloud...
>>>
>>> Is read mode appropriate? The user can edit the statefile and restart
>>> it. Admittedly the restart code should then do all the appropriate
>>> checks for recreating resources, but I'm having a hard time thinking
>>> through this straight.
>>>
>>> Let's say hallyn is running passwd. ruid=500,euid=0. He quickly
>>> checkpoints. Then he restarts. Will restart say "ok, the /bin/passwd
>>> binary is setuid 0 so let hallyn take euid=0 for this?" I guess not.
>>> But are there other resources for which this is harder to get right?
>> I'd say that checkpoint and restart are separate.
>>
>> In checkpoint, you read the state and save it somewhere; you don't
>> modify anything in the target task (container). This equivalent to
>> ptrace read-mode. If you could do ptrace, you could save all that
>> state. In fact, you could save it in a format that is suitable for
>> a future restart ... (or just forge one !)
>
> Yeah, that's convincing.
>
>> In restart, we either don't trust the user and keep everything to
>> be done with her credentials, of we trust the root user and allow
>> all operations (like loading a kernel module).
>>
>> We can actually have both modes of operations. How to decide that
>> we trust the user is a separate question: one option is to have
>> both checkpoint and restart executables setuid - checkpoint will
>> sign (in user space) the output image, and restart (in user space)
>> will validate the signature, before passing it to the kenrel. Surely
>> there are other ways...
>
> Makes sense.
>
> ...
>
>>> Hmm, so do you think we just always use the caller's credentials?
>> Nope, since we will fail to restart in many cases. We will need a way
>> to move from caller's credentials to saved credentials, and even from
>> caller's credentials to privileged credentials (e.g. to reopen a file
>> that was created by a setuid program prior to dropping privileges).
>
> Can we agree to worry about that much much later? :) Would you agree
