Resetting or rolling back ACLs - need formalization of storage controller?

[megoth]

It's not too uncommon that apps or developers corrupt ACLs. To mitigate this it would be nice if Pod owners can reset or roll back ACLs to an uncorrupted state.

I know this feature requires multiple components, such as the server being able to store changes to ACLs, but I wanted to highlight the problem that if an ACL is corrupted, how do the server know who can reset or rollback the ACL?

A strategy might be to look at the parent ACL and allow WebIDs who have control access there to trigger some sort of reset or rollback. This won't work for the root ACL though.

Another strategy might to enforce that ACLs never get corrupted, but I suspect this can be difficult to enforce, and this validation might introduce other problems.

I might be going about this the wrong way, but thought it prudent to create an issue on this to hear what the panels think about this.

This issue might also be related to the issues "Should it be possible to find owner of storage via resources?" and "Discoverability of root and controllers of Pods - some thoughts".

[zenomt]

i believe this situation should be handled as an implementation detail and area for differentiation of pod/storage providers. this situation is essentially an "owner or admin override" (aka superuser for the storage), where whatever access, even if for repair purposes, is outside of the control of Web Access Control.

this could take the form of (for example) direct filesystem access via command line/SSH or FTP, or an admin web app that can adjust (or maybe just repair) permissions, or something else entirely.

that said, it would be nice ("SHOULD [RFC 2119]") if a storage server at least wouldn't let you set/replace/patch an access control resource to a corrupt form. but then what counts as corrupt? just a syntactically invalid representation? missing controller? storage's owner(s) isn't a controller?

a differentiated feature could be that a storage server, no matter what you upload as an ACL, ensures that the "owner(s)" always have acl:Control by adding an acl:Authorization granting it.

[matsberg]

True. It is very easy to get out of Control as things are right now.