[Devel] Re: Creating tasks on restart: userspace vs kernel

[Oren Laadan]

Alexey Dobriyan wrote:
>>> In the end correctness of chopping will be equal to how good user
>>> understands that two task_struct's are independent of each other.
>>>
>>>> But it will still be a useful tool for many use cases, like batch cpu jobs,
>>>> some servers, vnc sessions (if you want graphics) etc. Imagine you run
>>>> 'octave' for a week and must reboot now - 'octave' wouldn't care if
>>>> you checkpointed it and then restart with a different pid !
>>>>
>>>> <3> Clone with pid:
>>>>
>>>> To restart processes from userspace, there needs to be a way to
>>>> request a specific pid--in the current pid_ns--for the child process
>>>> (clearly, if it isn't in use).
>>>>
>>>> Why is it a disadvantage ?  to Linus, a syscall clone_with_pid()
>>>> "sounds like a _wonderful_ attack vector against badly written
>>>> user-land software...".  Actually, getting a specific pid is possible
>>>> without this syscall.  But the point is that it's undesirable to have
>>>> this functionality unrestricted.
>>>>
>>>> So one option is to require root privileges. Another option is to
>>>> restrict such action in pid_ns created by the same user. Even more so,
>>>> restrict to only containers that are being restarted.
>>> You want to do small part in userspace and consequently end up with hacks
>>> both userspace-visible and in-kernel.
>> I want to extend existing kernel interface to leverage fork/clone
>> from user space, AND to allow the flexibility mentioned above (which
>> you conveniently ignored).
>>
>> All hacks are in-kernel, aren't they ?
> 
> mktree.c can be vieved as hack, why not?

Lol .. I meant "all kernel hacks are in-kernel" :)

> 
> The whole existence of these requirements. You want new syscall or SET_NEX_PID
> or /proc file or something.

Or embed it into a restart(2) call with special argument.

> 
>> As for asking for a specific pid from user space, it can be done by:
>> * a new syscall (restricted to user-owned-namespace or CAP_SYS_ADMIN)
>> * a sys_restart(... SET_NEXT_PID) interface specific for restart (ugh)
>> * setting a special /proc/PID/next_id  file which is consulted by fork
> 
> /proc/*/next_id was disscussed and hopefully died, but no.
> 
>> and in all cases, limit this so it can only allowed in a restarting
>> container, under the proper security model (again, e.g., Serge's
>> suggestion).
>>
>>> Pids aren't special, they are struct pid, dynamically allocated and
>>> refcounted just like any other structtures.
>>>
>>> They _become_ special for you intended method of restart.
>> They are special. And I allow them not to be restored, as well, if
>> the use case so wishes.
> 
> The use case is to restore as much as possible to the same state as
> equal as possible. Not going with fork_with_pid() in any form helps
> kernel to ensure correctness of restore and helps to avoid surprise
> failure modes from user POV.
> 
>>> You also have flags in nsproxy image (or where?) like "do clone with
>>> CLONE_NEWUTS".
>> Nope. Read the code.
> 
> Which code?
> 
> 	static int cr_write_namespaces(struct cr_ctx *ctx, struct task_struct *t)
> 	{
> 		...
> 
> 		new_uts = cr_obj_add_ptr(ctx, nsproxy->uts_ns,
> 					&hh->uts_ref, CR_OBJ_UTSNS, 0);
> 		if (new_uts < 0) {
> 			ret = new_uts;
> 			goto out;
> 		}
> 
> 		hh->flags = 0;
> 		if (new_uts)
> 	===>		hh->flags |= CLONE_NEWUTS;
> 
> 		ret = cr_write_obj(ctx, &h, hh);
> 			...
> 
>>> This is unneeded!
>>>
>>> nsproxy (or task_struct) image have reference (objref/position) to uts_ns image.
>>>
>>> On restart, one lookups object by reference or restore it if needed,
>>> takes refcount and glue. Just like with every other two structures.
>> That's exactly how it's done.
> 
> Not for uts_ns and future namespaces.
> 
> 	ret = cr_restore_utsns(ctx, hh->uts_ref, hh->flags);
> 						 ^^^^^^^^^
> 						 comes from disk

Where else would it come from ?  that's part of the state saved during
checkpoint.

That's for nested UTS namespaces, where a task in container called
unshare().

Oren.

_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers