On Thu, Jul 24, 2025 at 4:00 PM Al Viro viro@zeniv.linux.org.uk wrote:
On Thu, Jul 24, 2025 at 01:02:48PM -0700, Andrei Vagin wrote:
Hi Al and Christian,
The commit 12f147ddd6de ("do_change_type(): refuse to operate on unmounted/not ours mounts") introduced an ABI backward compatibility break. CRIU depends on the previous behavior, and users are now reporting criu restore failures following the kernel update. This change has been propagated to stable kernels. Is this check strictly required?
Yes.
Would it be possible to check only if the current process has CAP_SYS_ADMIN within the mount user namespace?
Not enough, both in terms of permissions *and* in terms of "thou shalt not bugger the kernel data structures - nobody's priveleged enough for that".
Al,
I am still thinking in terms of "Thou shalt not break userspace"...
Seriously though, this original behavior has been in the kernel for 20 years, and it hasn't triggered any corruptions in all that time. I understand this change might be necessary in its current form, and that some collateral damage could be unavoidable. But if that's the case, I'd expect a detailed explanation of why it had to be so and why userspace breakage is unavoidable.
The original change was merged two decades ago. We need to consider that some applications might rely on that behavior. I'm not questioning the security aspect - that must be addressed. But for anything else, we need to minimize the impact on user applications that don't violate security.
We can consider a cleaner fix for the upstream kernel, but when we are talking about stable kernels, the user-space backward compatibility aspect should be even more critical.
Thanks, Andrei