Serge E. Hallyn wrote:

Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):

quoted

Serge E. Hallyn wrote:

quoted

Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
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.

quoted

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.

...

quoted

quoted

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

Definitely. Even more so - I believe that's a user-space issue :)

that for the majority of use-cases, restarting with caller's credentials
will work?  Or am I wrong about that?

That depends on your target audience. For HPC you're probably right.
For server applications this may not be the case (e.g. apache needs
a privileged port, and then it drops privileges).

I agree that we may safely (...) defer this discussion until the
implementation gets much beefier.

quoted

To do that, we will need to agree on a way to escalate/change the
credentials. This however belongs to user-space (and then the binaries
for checkpoint/restart will be setuid themselves).

Ok those are less scary, and I have no problem with those.

quoted

There will also be the issue of mapping credentials: a user A may have
one UID/GID on once system and another UID/GID on another system, and
we may want to do the conversion. This, too, can be done in user space
prior to restart by using an appropriate filter through the checkpoint
stream.

User namespaces may help here too.  So user A can create a new user
namespace and restart as user B in that namespace.  But right now that
sounds like overkill.

Indeed, virtualization is probably the solution. Here, too, I think
it's safe to defer the discussion.

Oren.


--
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