The Apply recipe action (eca_apply_recipe) was
previously available to any account. Its access() only checked that
the configured package name resolved to an installed recipe path, and otherwise
returned allowed.
It now additionally requires the executing account to hold the
administer site configuration permission. Applying a recipe
installs modules and executes config actions, which is at least as privileged as
any other configuration operation in ECA.
Before
$result = AccessResult::allowed();
if ($this->getRecipePath($this->configuration['recipe_package_name']) === NULL) {
$result = AccessResult::forbidden('The configured package name is invalid.');
}
After
$result = AccessResult::forbidden('The user does not have the permission to administer site configuration.');
$account = $account ?: $this->currentUser;
if ($account->hasPermission('administer site configuration')) {
$result = AccessResult::allowed();
if ($this->getRecipePath($this->configuration['recipe_package_name']) === NULL) {
$result = AccessResult::forbidden('The configured package name is invalid.');
}
}
What you need to check
This can silently disable a working model. ECA treats a
denied action as "skip", not as an error. A model that applies a recipe under an
account without administer site configuration will simply stop
applying it, with no visible failure - only an access denial reason in the
log.
Review every model using Apply recipe and determine which account it
actually executes as. That is the triggering user, unless the model switches
accounts or the Execute models as setting names a different user. Grant
administer site configuration to that account, or switch to a
service account that holds it before the action runs.
Models that already run as user 1 or as an administrator are unaffected.
