Device service controls: verify principal authority before dispatch

Ouverte
  • Quelque chose ne va pas ?
#483 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
38/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
rust
Domaine
authorization, backend, security

Piste de recherche

Read the shared device service control operation at the stated develop and candidate revisions, then trace how human, app, and agent entry points reach dispatch. The issue does not identify paths or configuration conditions; begin by locating that operation and its existing tests. Done means the owner policy is enforced before dispatch, isolated tests show zero effects for disallowed or revoked principals and success for the approved path, and independent review records release impact.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Intended behavior

Runtime applies the approved principal-role policy to device-level service controls before it dispatches an effect. Human, app and agent entry points receive the same decision. Status reads can have a separately defined policy.

The #93 audit found a source-level authority question that needs verification before release triage. Detailed paths and configuration conditions are retained in the private audit evidence. This public issue deliberately records only the required contract and proof. Installed reachability and impact are unverified.

Source boundary: develop 3beb816438fd567145a8d725e22465bd83277cf0 and local candidate 460b1888d344f52cebd1c25866be88ff4085f035. The candidate contains the same relevant path.

Acceptance

  • The owner states which principals may change the device service state.
  • Runtime enforces that policy in the shared operation before dispatch.
  • An isolated fixture records zero effects for disallowed and revoked principals.
  • The approved owner path succeeds with the required proof.
  • Human and agent entry points receive equivalent decisions.
  • Independent security review records the candidate and whether this blocks 0.8.0 or has an explicitly accepted restricted scope.

Related: #178 and #464 own the broader approval/policy work. This issue owns the narrow verification from the current release audit. It starts no live-host testing or configuration change.

Langage dominant
Rust
Étoiles
6
Forks
2
Merge moyen
1 j 3 h
PR mergées (30 j)
42

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de elastos/elastos-runtime

Toutes les issues de elastos/elastos-runtime

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.