Origins and namespaces each take their own list of capabilities ("Reads", "PublicReads", "Writes", "Listings", "DirectReads") that indicate what the administrator would like to permit for the resource.

However, our mechanisms to enforce these capabilities at the Origin are only semi-functional, mostly relying on XRootD's Scitokens authorization library. In some cases, certain combinations of capabilities may allow unexpected behavior if the origin receives a broadly permissive, validly-signed token. This happens because we have no way telling XRootD that it should accept or deny tokens based on their prescribed claims -- only that certain issuers are allowed to issue tokens for certain base paths.

For example, if an Origin is configured only with the authorized "Reads" as a capability, an entry is added to the Origin's XRootD Scitokens config that describes permitted issuers and the base paths those issuers are allowed to mint tokens for. If a properly-signed storage.Modify token arrives at the Origin along with a PUT request, we'd expect the Origin to deny the token because it does not have the "Writes" capability. However, the authorization library has no way of knowing this, so the token will be accepted and the XRootD endpoint will attempt to move forward with the write.

Until the XRootD Scitokens auth library has a way to describe which actions/verbs/scopes are allowed from certain issuers for a given path, I don't think there's much we can do about this. On one hand, we do handle some filtering in the Director, and in theory we shouldn't ever send a client to a non writable origin if the client sends the director a PUT request. However, @Saartank has observed some cases where the Director doesn't handle this correctly.

Finally, I'll note that this assumes the issuer is minting broadly-permissive tokens. If the issuer chooses only to issue tokens with capabilities aligning with the Origin's wishes, there's no issue. But in a world where origins and issuers can be two separate entities, I don't think it's great to rely on a policy in one place being correctly translated into a policy for a separate, autonomous entity even if there's an inherent trust relationship between the two.