clone will pass the return value of the start function to SYS_exit
anyway; there's no need to call the syscall directly.

the child process's stack may be insufficient size to support a signal
frame, and there is no reason these signal handlers should run in the
child anyway.

this is another case of the kernel syscall failing to support flags
where it needs to, leading to horrible workarounds in userspace. this
time the workaround requires changing uid/gid, and that's not safe to
do in the current process. in the worst case, kernel resource limits
might prevent recovering the original values, and then there would be
no way to safely return. so, use the safe but horribly inefficient
alternative: forking. clone is used instead of fork to suppress
signals from the child.

fortunately this worst-case code is only needed when effective and
real ids mismatch, which mainly happens in suid programs.