prashanthr2 opened a new issue, #14174:
URL: https://github.com/apache/cloudstack/issues/14174
### 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
1. Create a project and add a normal user to it as Project Admin.
2. As that user, register a template into the project with
`isextractable=true` and
`ispublic=true`. Both are accepted.
3. As the same user, try to change either flag:
update templatepermissions id=<template-uuid> isextractable=false
Expected: succeeds — the same user set the flag two steps ago.
Actual:
Unable to grant permission to Account <name> as it is neither admin nor
owner or the Template
4. 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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
