I won't apply this version, please send v6 with the changes below.
On Tue, 10 Nov 2026 18:26:52 +0100, Vladimir Riabchun
<[email protected]> wrote:
> Modify ovl_override_creds so that it returns both old cred and old VE.
> This will also protect us from future rebase issues - all new users of
> old_cred and ovl_override_creds will fail with compilation error.
- Item 8 of the cover letter reply: add a Fixes tag for ec01a90d0ef9
("ovl: replace capable by ve_capable for indexing feature"), limit
this claim to ovl_override_creds() callers, say why cross-CT use
must fail, and fix "swich" and "Stroing".
ec01a90d0ef9 turned capable() into ve_capable() in
ovl_can_decode_fh() and ovl_decode_real_fh(). That made the result
depend on the VE, which is the bug.
The compile error catches new ovl_override_creds() callers only.
ovl_creds() users, such as backing_file_ctx.cred in read/write/splice/
mmap, still switch creds without the VE.
> We don't allow cross-CT overlayfs usages, it is broken and reported
> as -EINVAL. But we want to allow usage of host-owned overlayfs by CT.
"It is broken" does not say why the error is needed. If a CT-B task
kept its own VE on a CT-A overlay, CT-A creds would be checked
against CT-B's user namespace. That fails at run time, while the
mount-time check passed, and it is the same oops again. Please say
that in the message, since Pavel's "just skip the override" looks
like the simpler choice otherwise.
> + /*
> + * We want to allow passing host overlayfs to CT.
> + * It is fine to keep CT ve - host creds should work.
> + * Cross-CT mounts are forbidden.
> + */
> + if (IS_ERR(desc->ve) && PTR_ERR(desc->ve) != -EPERM)
> + return PTR_ERR(desc->ve);
- Item 1 of the cover letter reply: test only IS_ERR() here and in
ovl_revert_creds(), once override_ve() returns old_ve for the VE0
case. Fix the comment: mounting works, using the overlay from
another CT is refused.
The user-visible errno also changes then: stat, open and lookup on a
foreign CT's overlay return EPERM rather than EINVAL. EINVAL there
reads as a bad argument from the caller.
--
Konstantin Khorenko,
Virtuozzo Linux Kernel Team
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
