kerndat: Skip clone3(set_tid) when unprivileged.

[osctobe]

A set of fixes for kerndat tests and a few debug logging improvements.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (cda1c5c) 70.51% compared to head (e2ae63e) 70.50%.

❗ Current head e2ae63e differs from pull request most recent head ff088a7. Consider uploading reports for the commit ff088a7 to get more accurate results

Additional details and impacted files

@@             Coverage Diff              @@
##           criu-dev    #2252      +/-   ##
============================================
- Coverage     70.51%   70.50%   -0.01%     
============================================
  Files           133      133              
  Lines         33534    33534              
============================================
- Hits          23646    23643       -3     
- Misses         9888     9891       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[avagin]

Pretend it's not available instead of failing restore later when running unprivileged.

Can restore succeed if kdat.has_clone3_set_tid isn't set and criu is running w/o cap_sys_admin and cap_cr?

[osctobe]

Yes. It does it using the old method: by using ns_last_pid (via a RPC helper).

[avagin]

Let's write a comment to explain this in the code.

[avagin]

I think this isn't a right solution for the problem:

• process can be restored in a separate user and pid namespaces and clone3() works fine in this case.
• this function checks whether clone3 is supported or not, and it is separate from the dump/restore code. I think we have to move these checks to the code that restores processes with specified pids.

[osctobe]

So we should we treat EPERM here as success (clone3 with set_tid supported)? (And add a fallback path in the restoring code. [separate change])

[avagin]

yes, you are right.

[Snorch]

Hello @avagin and @osctobe, I had one idea, which I like a lot, but guys in mainstream Linux faced it with total silence.

The idea was to allow clone3 syscall to alter owner user namespace of newly created namespaces (e.g. new pid namespace owner if CLONE_NEWPID is specified). https://lore.kernel.org/all/20210402155131.119872-1-ptikhomirov@virtuozzo.com/

This way using clone3 CRIU is able to create all restored processes in topmost user namespace available, while preserving namespace ownership topology. So at each clone3 call we would have all permissions needed by clone3_set_tid functionality. (Later we can switch to proper user namespace for each process to also preserve task's user namespaces.)

I believe my fix would help in this case too. @osctobe Can you, please, give it a try on your environment?

[github-actions]

A friendly reminder that this PR had no activity for 30 days.