Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate how descendent roles are handled regarding read #691

Open
Tracked by #806
thehenrytsai opened this issue Feb 16, 2024 · 0 comments
Open
Tracked by #806

Investigate how descendent roles are handled regarding read #691

thehenrytsai opened this issue Feb 16, 2024 · 0 comments
Labels
good first issue Good for newcomers hacktoberfest For the hacking month of October testing related to new or existing tests

Comments

@thehenrytsai
Copy link
Member

thehenrytsai commented Feb 16, 2024

Goal: confirm with @csuwildcat on expected behavior, investigate if actual behavior matches outcome, write tests if they don't already exist.

Maybe everything works, but it is unclear to me how the descendent (context) role declared in thread-role.json is being used for protocol authorization:

    "thread": {
      "$actions": [
        {
          "role": "thread/participant",
          "can": "read"
        }
      ],

It would be good to investigate if this is a special case only because we so happen to have the contextId of the thread? What happens if the descendent role specified is deeper, e.g. thread/foo/bar/baz, just to make sure there is no security holes.

Additional info I added at the time of this issue creation, but no longer remember/understand why but afraid to remove:


If we were to disallow descendent roles, we'd do:

      // Validate the `role` property of an `action` if exists.
      if (action.role !== undefined) {
        // make sure the role specified is self, or uncle, or great uncle, or separate root record
        // ie. the role record specified should must share the same "ancestor-chain" with the record of this rule set
        // e.g. if the rule set protocol path is `a1/b1/c1` then the role record can be `a2` (an edge case), `a1/b2`, `a1/b1/c1`, `a1/b1/c2`
        // but NOT `a1/b2/c3`, or `a1/b2/c1/d1`.
        const ruleSetParentProtocolPath = ruleSetProtocolPath.substring(0, ruleSetProtocolPath.lastIndexOf('/')); // NOTE: substring(0, negative-number) returns empty string which is what we want
        const roleParentProtocolPath = action.role.substring(0, action.role.lastIndexOf('/'));
        if (!ruleSetParentProtocolPath.startsWith(roleParentProtocolPath)) {
          throw new DwnError(
            DwnErrorCode.ProtocolsConfigureRoleDoesNotShareSameAncestorsAsRuleSetRecord,
            `Role in action ${JSON.stringify(action)} for rule set ${ruleSetProtocolPath} does not share the same ancestors as the rule set record.`
          );
        }
@thehenrytsai thehenrytsai added the testing related to new or existing tests label Feb 16, 2024
@thehenrytsai thehenrytsai added good first issue Good for newcomers hacktoberfest For the hacking month of October labels Sep 13, 2024
@thehenrytsai thehenrytsai changed the title Investigate how descendent roles are handled Investigate how descendent roles are handled regarding read Sep 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers hacktoberfest For the hacking month of October testing related to new or existing tests
Projects
None yet
Development

No branches or pull requests

1 participant