should faild if the permission is not created when linkauth,but now it success.

[bluepeople1]

void apply_eosio_linkauth(apply_context& context) {
// context.require_write_lock( config::eosio_auth_scope );

auto requirement = context.act.data_as();
try {
EOS_ASSERT(!requirement.requirement.empty(), action_validate_exception, "Required permission cannot be empty");

  context.require_authorization(requirement.account); // only here to mark the single authority on this action as used

  auto& db = context.db;
  const auto *account = db.find<account_object, by_name>(requirement.account);
  EOS_ASSERT(account != nullptr, account_query_exception,
             "Failed to retrieve account: ${account}", ("account", requirement.account)); // Redundant?
  const auto *code = db.find<account_object, by_name>(requirement.code);
  EOS_ASSERT(code != nullptr, account_query_exception,
             "Failed to retrieve code for account: ${account}", ("account", requirement.code));
  if( requirement.requirement != config::eosio_any_name ) {
     **const auto *permission = db.find<permission_object, by_name>(requirement.requirement);**
     EOS_ASSERT(permission != nullptr, permission_query_exception,
                "Failed to retrieve permission: ${permission}", ("permission", requirement.requirement));
  }

this cause linkauth permission success when the requirement permission exists but the permission is not created by the account.

[arhag]

Indeed this is an oversight.

After reviewing the permission/authorization code I can claim that the only implications of this oversight are less safeguards by the chain to prevent the user from inconveniencing themselves.

A user is still not able to link to the empty permission (which is good because otherwise they would never be able to unlink it), nor to any of the eosio.* permissions other than eosio.any (which is the desired behavior). And if they do link to eosio.any, they can easily unlink it.

However, this bug means that a user could potentially link to a permission that does not actually exist under their account. The implications of that are:

• The linked action(s) are not satisfiable by the account during authorization checking until they unlink it or relink it to an existing permission that can be satisfied. This means that the user would not be able to add their account as an authorizer to affected actions as long as that bad link remains.
• Unlinking or relinking would not be possible until the permission that the bad link points to is created by the account.
• Any existing permission of the account could create the missing permission. This means users should not rely on this bug as a security mechanism for making certain actions unsatisfiable. It would effectively have the nearly the opposite meaning: something closer to an eosio.any permission.

Furthermore, this bug breaks the previously assumed invariant that all permission links map to an existing permission. Fortunately, our code has not yet relied on that invariant in any way that would lead to a security issue (to my knowledge). Even if this bug is fixed in a future consensus protocol upgrade, we cannot rely on that invariant going forward since there may be existing broken links that were created before the consensus protocol feature activation.

Additionally, we could add subjective mitigations to protect against this relatively soon rather than waiting until a consensus protocol feature activation before anything is done about it.

[arhag]

The objective fix to this bug is tracked in #6333. This issue is left to track a subjective mitigation that rejects eosio::linkauth if it links to a non-existing permission.

[arhag]

There is no real need for a subjective mitigation since this isn't a security issue and the proper fix has been implemented as part of the protocol feature introduced in #6831.