On 11/12/26 21:41, Vladimir Riabchun wrote:
> I disagree. CT -> Host VE switch is not a normal case. We know it is
> fine for overlayfs, but for other cases we should review it separately,
> if this is a correct usage or CT is doing something nasty.

Agreed, a silent no-op would hide the request: the next user of
override_ve() would run with the host creds and the CT VE without
knowing it.

On the other hand, an API that returns an error the caller has to go
on after is a bad API too. Then let us change item 1 so that both hold.

override_ve() reports only "switched" or "refused": a CT task asking
for any other VE, VE0 included, gets ERR_PTR(-EPERM) and the
ratelimited message. Any error pointer is then a real refusal.

overlayfs handles its own case before the call: a host overlayfs used
from a CT keeps the CT VE and overrides only the creds, without calling
override_ve(). Something like:

        if (ve_is_super(ofs->creator_ve) && !ve_is_super(get_exec_env())) {
                /* Host overlayfs used from a CT: host creds work there. */
                desc->ve = NULL;
                desc->ve_overridden = false;
        } else {
                desc->ve = override_ve(ofs->creator_ve);
                if (IS_ERR(desc->ve))
                        return PTR_ERR(desc->ve);
                desc->ve_overridden = true;
        }
        desc->cred = override_creds(ofs->creator_cred);

ovl_revert_creds() returns at once on IS_ERR(desc->ve), a failed
override (ovl_copy_up_flags() still calls it after one), reverts the
creds otherwise, and the VE only when ve_overridden is set. A flag and
not a NULL desc->ve, since NULL is a valid previous override.

overlayfs then never gets the message for its allowed case, and no
PTR_ERR() != -EPERM is left. Items 2 and 3 stay as they are.

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team


_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel

Reply via email to