Add a new Inherited access control policy

[dylanmcreynolds]

Checklist

• Add a Changelog entry
• Add the ticket number which this PR closes to the comment section

The default TagAccessPolicy requires that every node in the tree be tagged with access_tags. I think this creates a lot of future maintenance. If I were to try and change access for container of, say, proposals, I would have to make sure to surgically change the access_tag of every node under the proposal container. I'd rather just change the proposal container.

We also use tiled for storing processed data. The current setup puts a lot of responsibility on applications writing to tiled to get know how to tag every node that it writes. Using inheritance eases this.

Introduces InheritedTagAccessPolicy, a new access policy that extends TagBasedAccessPolicy by walking the node hierarchy when a node has no access tags of its own. Instead of defaulting to no access, it looks up the nodes_closure table to find the nearest tagged ancestor and applies that ancestor's access control rules. It ends at the first ancestor node that has at least one tag and uses that.

Also adds AccessBlobInheritedFilter to support filtering nodes by inherited access, and includes tests covering inherited access scenarios.

[checkmarx-gh-ast-us-povs]

Checkmarx One – Scan Summary & Details – b6c866d4-ad42-4681-812d-a9db55f1e772

Great job! No new security vulnerabilities introduced in this pull request

---

Communicate with Checkmarx by submitting a PR comment with @Checkmarx followed by one of the supported commands. Learn about the supported commands here.

[danielballan]

Notes from in-person discussion on June 5

• @nmaytan will review and approve @dylanmcreynolds' PR.
• We will merge that with its current scope.
• Scope for future PRs:
  • Tiled client should be able to ask, "What tags will I inherit if I create a child node here?"
  • Tiled client's tree command should be able to display tags on each line
  • Refactor access_blob to access_tags (either array of strings or many-to-many association to a separate table)
  • default_access_tags distinct from access_tags
    • If you have a container that has some access on it that might not necessarily be the access you want inherit by something that's inside of it. The access for something inside the container should be a different set of tags.
    • This is a way of giving broader access on contents than you have on the root, just as users have write access to the contents of a proposal directory but not to the directory itself.
    • We are not enamored with the named default_; let's workshop that with Claude.
    • Explore the consequence of this rule: just as with POSIX ACLs, if default_accesss_tags is not set, it's not a candidate for inheritance.
    • In the NSLS2 migration, un-tag everything under each BlueskyRun and update default_access_tags on them.
• At ALS, TiledWriter/user can easily create /smi/raw/prop-12345. All scans for the proposal go in there.
• Connecting AuthZ to the graph-of-links work:
  • For now, as entities always refer to nodes in Tiled, we don't need access tags on entities themselves. When, in the future, we extend entities to refer to external resources, we'll need to revisit this.
  • Links will have access tags on them.
  • Access to a link is determined by access to the link itself and both linked nodes.