Clarify the lifecycle of an ACL resource

[acoburn]

Parent issue: #102 - Specify approach for resource meta-data.

Version 0.5 of the Solid Web Access Control specification is silent about the lifecycle of an ACL resource with regard to the resource to which it is attached.

The position of the specification on this point has significant architectural implications for an implementation, and I would appreciate thorough consideration of this issue.

Much of this involves the intersection of LDP and WebAC. Specifically:

1. Are ACL resources a special sort of LDP resource, following LDP rules of containment? If so, what is it, semantically, that distinguishes these resources from non-ACL resources?

2. Alternatively, do ACL resources have a different semantic relationship to normal LDP resources, separate from LDP containment. One can reasonably arrive at this conclusion, given that ACL discovery proceeds through Link headers rel="acl"

If interpretation (1) is followed, is an ACL resource still addressable after the resource it is connected to is deleted? (i.e. /container/resource is deleted, but /container/resource.acl is not). If an ACL persists after the resource is deleted, what happens if another resource is created (much later) at that location? Are there security issues to consider in this case, especially if the creator of that new resource finds that an unknown ACL now applies to a resource that was, apparently, just created anew. Furthermore, if the resource and its ACL have distinct lifecycles, does this mean that a container cannot be deleted unless all (potentially orphaned) ACLs are first deleted? It is worth noting that this appears to be how IPS has been implemented.

If interpretation (2) is followed, then ACL statements are treated as (addressable) metadata on a resource. When a resource is deleted, all corresponding ACL metadata is cleaned up automatically. This is similar to how a standard filesystem functions: ACL controls are not typically viewable as distinct files with an $ ls command. This pattern of "addressable resource metadata", where separate resources have lifecycles bound together appears also to be a viable architecture for working with Shape validation metadata.

[RubenVerborgh]

When a resource is deleted, all corresponding ACL metadata is cleaned up automatically.

Just want to make a security note here, if we go this way, we should ensure that this cannot be abused to gain different permissions to a file. Suppose there is a document to which others append things, which I am not allowed to read. If I can somehow get the document deleted, the next append might cause it to be created, but this time without its ACL file.

[pmcb55]

@RubenVerborgh I don't see a major security worry here. Shouldn't appending to a non-existent (e.g. just deleted) resource either fail with a 404, or create the resource with an owner-access-only ACL?

[RubenVerborgh]

Shouldn't appending to a non-existent (e.g. just deleted) resource either fail with a 404

Not necessarily (#42).

or create the resource with an owner-access-only ACL?

That could be one possible solution, but that is currently not the case. At the moment, it would fall back to the parent ACL.

[kjetilk]

The position of the specification on this point has significant architectural implications for an implementation, and I would appreciate thorough consideration of this issue.

Indeed, as a meta-comment, I think we should have a label for the issues that has significant architectural implications like this one, because I think we should prioritize them, as the cost of a late resolution is potentially very high.

[dmitrizagidulin]

Adding a related/original issue: solid/solid#251 (We should either close that one now, or when this issue (58) gets resolved.)

[dmitrizagidulin]

See also: solid/solid-spec#187

[jeff-zucker]

Some additional points that may be more implementation than spec but that bear thinking about: 1) A minor typo in an .acl file can make it such that no one but a server admin can delete or modify the .acl or the resource it controls. 2) If a resource is deleted and its .acl remains, the .acl is undiscoverable and its container undeleteable 3) It is not safe to replace a .acl file with POST since it would require a non-atomic delete/save leaving the associated resource uncontrolled in the interim. If the answer to this is PUT, that should inform #40,

[dmitrizagidulin]

+1 to @jeff-zucker's comment above. It's super easy to lock a user out of their accounts now (via a stray modification of an .acl), with no account recovery mechanism available. We should probably fix that.

[kjetilk]

Yeah, I had a user story about that. I'll write a separate issue on it.

[pmcb55]

So just my 2c - I think the conceptual separation of a resource and it's ACL (as a standalone, separate resource) might simply be a fundamental mistake (which, as @RubenVerborgh points out is indeed the current state of affairs (solid/solid-spec#187 (comment))). Instead I think the Unix inode concept of them being atomically related (as stated by @melvincarvalho (solid/solid#251 (comment))) is a much better mental model.

Personally I really like the model of treating a resource's ACL as meta-data on that resource itself (which @acoburn introduced me to originally). With that model, deleting the resource deletes all explicitly associated meta-data, including any resource-specific ACL data. But since the ACL is just meta-data, it can easily support the notion of 'inheriting' ACL data from parent resources, i.e. it becomes by-reference as opposed to by-value (and resource deletion includes by-value-meta-data-also deletion).

It seems one justification for the separation of ACL's into standalone resources is that they'll be automatically re-instated if a deleted resource is restored. But if a deleted resource can be restored at all, then surely any 'part' of it can be restored or subsequently reused too, and so I don't see any problem in being able to restore or reuse just the ACL meta-data if needed later.

What this model does open up though I suppose is a generic, spec-defined way to refer to, access and update resource-meta-data (i.e. not just ACL data, but any meta-data associated with a resource). I'm not sure if Solid addresses that question already somewhere (but I suspect Link headers might be an option...?!).

But rather than distract into that discussion, I'd like to better understand any other justifications for continuing with an explicit separation of resource and ACL resource.

[kjetilk]

I think it is interesting to entertain that idea, in fact, I see many interesting things happening from not separating data and metadata without a very good reason to.

However, it seems to me it would be a radical departure from Solid as currently designed, with the resource itself and its ACL being different information resources with distinct URIs and requiring different HTTP requests. Atomic operations across several HTTP requests across several resources aren't terribly easy AFAICS (though I have some loose ideas). Within that design, I find it difficult to think about operations on them as atomic, and thus, a mental model that is not aligned with that practical constraint difficult to entertain.

[kjetilk]

So, as people might have noticed elsewhere, I have changed my mind concerning atomicity and side-effects. :-) So, I'm now more inclined to consider the resource and its metadata as an atom.

[csarven]

Proposal following 2019-12-04:

Consensus: Deleting a resource must remove associated ACL resource (re #31 ).

Need consensus: atomicity of creating a resource and its ACL eg. does the ACL get created before or after resource? #131

[RubenVerborgh]

Can we list the “why” of the above consensus?

…

-- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged, confidential and/or proprietary information. If you are not the intended recipient of this e-mail (or the person responsible for delivering this document to the intended recipient), please do not disseminate, distribute, print or copy this e-mail, or any attachment thereto. If you have received this e-mail in error, please respond to the individual sending the message, and permanently delete the email.

[csarven]

One of the reasons is to not have dangling ACLs as part of the clean-up process. The other reason is that there is no deterministic ACL naming as per spec, and neither can it be expected that when a server reinstates a resource (using the same name as before), its ACL will use the same URL - so potentially dangling ACL. IIRC, beyond looking into 131 orthogonally, there wasn't a significant use case to allow an ACL to exist beyond the life of a resource using it. This excludes inherited ACLs of course.