problem
A project user can set ispublic and isextractable when registering a template into a project,
but cannot change either one afterwards. Not even the Project Admin can. Only a domain or root
admin can, so a project cannot manage the permissions of its own templates.
updateTemplatePermissions fails with:
Unable to grant permission to Account <name> as it is neither admin nor owner or the Template
from TemplateManagerImpl.updateTemplateOrIsoPermissions():
//Only admin or owner of the template should be able to change its permissions
if (caller.getId() != ownerId && !isAdmin) {
throw new InvalidParameterValueException("Unable to grant permission to Account " + caller.getAccountName() + " as it is neither admin nor owner or the Template");
}
caller is always the human user's own account, while ownerId for a project template is the
project account, so the two can never be equal for a project member and every non-admin caller is
rejected.
Registration applies no such restriction: in TemplateAdapterBase.prepare() isextractable is
taken from the caller with no privilege check, and ispublic is gated only by
allow.public.user.templates.
This is not an escalation issue, an admin can revoke the flags, and the user could already set
them at upload. It is the inconsistency between the two paths that needs fixing.
versions
CloudStack: reported on 4.20.3.0; the same code is in 4.20.3.1, 4.21.0.0 and current main
(TemplateManagerImpl line 1632 on 4.20.3.0, 1565 on 4.21.0.0, 1831 on main). Not a regression.
Hypervisor: reported on VMware; the code path is hypervisor-independent.
Affects templates and ISOs alike.
The steps to reproduce the bug
-
Create a project and add a normal user to it as Project Admin.
-
As that user, register a template into the project with isextractable=true and
ispublic=true. Both are accepted.
-
As the same user, try to change either flag:
update templatepermissions id= isextractable=false
Expected: succeeds — the same user set the flag two steps ago.
Actual:
Unable to grant permission to Account as it is neither admin nor owner or the Template
-
The same call as a root admin succeeds.
The UI behaves identically: the flags are settable in the upload dialog and rejected in template
settings afterwards.
What to do about it?
Make the two paths consistent. The natural fix is to let a project administrator act as the owner
for this check, so permissions on project-owned templates can be changed by the project that owns
them. Whether that should be any project member or only the Project Admin is worth stating
explicitly in the fix.
Useful starting point: the method already has a branch for this case a few lines earlier —
if (owner.getType() == Account.Type.PROJECT) {
// if it is a project owned template/iso, the user must at least have access to be allowed to share it.
_accountMgr.checkAccess(user, template);
}
but checkAccess can only reject, not grant, so callers who pass it still hit the owner/admin
throw below.
Also worth reconciling: the isextractable API description says "Can be set only by root admin",
which matches the update path but not the registration path.
problem
A project user can set
ispublicandisextractablewhen registering a template into a project,but cannot change either one afterwards. Not even the Project Admin can. Only a domain or root
admin can, so a project cannot manage the permissions of its own templates.
updateTemplatePermissionsfails with:from
TemplateManagerImpl.updateTemplateOrIsoPermissions():calleris always the human user's own account, whileownerIdfor a project template is theproject account, so the two can never be equal for a project member and every non-admin caller is
rejected.
Registration applies no such restriction: in
TemplateAdapterBase.prepare()isextractableistaken from the caller with no privilege check, and
ispublicis gated only byallow.public.user.templates.This is not an escalation issue, an admin can revoke the flags, and the user could already set
them at upload. It is the inconsistency between the two paths that needs fixing.
versions
CloudStack: reported on 4.20.3.0; the same code is in 4.20.3.1, 4.21.0.0 and current main
(TemplateManagerImpl line 1632 on 4.20.3.0, 1565 on 4.21.0.0, 1831 on main). Not a regression.
Hypervisor: reported on VMware; the code path is hypervisor-independent.
Affects templates and ISOs alike.
The steps to reproduce the bug
Create a project and add a normal user to it as Project Admin.
As that user, register a template into the project with
isextractable=trueandispublic=true. Both are accepted.As the same user, try to change either flag:
update templatepermissions id= isextractable=false
Expected: succeeds — the same user set the flag two steps ago.
Actual:
Unable to grant permission to Account as it is neither admin nor owner or the Template
The same call as a root admin succeeds.
The UI behaves identically: the flags are settable in the upload dialog and rejected in template
settings afterwards.
What to do about it?
Make the two paths consistent. The natural fix is to let a project administrator act as the owner
for this check, so permissions on project-owned templates can be changed by the project that owns
them. Whether that should be any project member or only the Project Admin is worth stating
explicitly in the fix.
Useful starting point: the method already has a branch for this case a few lines earlier —
but
checkAccesscan only reject, not grant, so callers who pass it still hit the owner/adminthrow below.
Also worth reconciling: the
isextractableAPI description says "Can be set only by root admin",which matches the update path but not the registration path.