Track who is the pod owner and allow them always control access.

[michielbdejong]

So you will be able to write protect a file still and even stop yourself reading it but you will always be able change that back.

See https://gitter.im/solid/chat?at=5f866ebe78d7f20c9faac119

[csarven]

• Which permissions are required for deleting a resource? solid/specification#197 (comment)
• Which permissions are required for deleting a resource? solid/specification#197 (comment)
• Should it be possible to find controller of storage via resources? solid/specification#153 (comment)

[michielbdejong]

Thanks for the links! But those are all proposed spec changes that haven't happend yet.

I'll implement it using the current spec.

And that's easy in this case, because only the pod server itself needs to know about this. In NSS it's always clear that the pod owner is either https://example.com/profile/card#me (for everything under https://example.com/, in single-user mode) or https://username.example.com/profile/card#me (for everything under https://username.example.com/, in multi-user mode).

[bourgeoa]

@michielbdejong I am personally in agreement with your choice for the current spec.
The owner should be the one allowed to delete the pod.
Can it be a different webId ? I dont know with the actual spec.

[bourgeoa]

Does this choice works for pod used has a storage extension ?

[bourgeoa]

@michielbdejong
Is Control enough ? I suppose what is needed is ReadwriteControl.

But in that case the owner is always authorized for the resource (folder, file).

I think that the expectation is a bit different. To have the owner have always access to ACL only.
A kind of back door to access the key to the front door.

[michielbdejong]

Yeah, if you have only Control then you can at least bootstrap yourself back into ReadWriteControl.

I don't have a lot of bandwidth for work like this at the moment, but it's good to have this issue documented in case one of us has some more time on their hands, e.g. on a Friday afternoon. :)

[timbl]

@michielbdejong friendly amendment: "So you will be able to CONTROL protect a file still and even stop yourself reading it but you will always be able change that back."

So if you are the owner of the pod , you will always be able to change the ACL. That doe NOT mean you will always automatically be able to read and write: you may have to change the ACL first. So you will still be able to protect yourself from reading or from writing files. But you will be able to change it back.

[timbl]

(To not confuse this issue with the questions about how the you can find the owner of the pod from a given resource in the pod -- that requires more specification and is much less urgent)

[csarven]

https://solidproject.org/TR/protocol#storage :

The root container (pim:Storage) MUST have an ACL auxiliary resource directly associated to it. The associated ACL document MUST include an authorization policy with acl:Control access privilege.

[csarven]

This issue is getting out of hand. We have the title saying one thing, the first comment is about something else .. then we are talking about what Control entails.. and above I pasted how to persist root ACL + Control.

Control is only about the ACL resource.

[bourgeoa]

@timbl @csarven
Taking this in consideration

The root container (pim:Storage) MUST have an ACL auxiliary resource directly associated to it. The associated ACL document MUST include an authorization policy with acl:Control access privilege.

and returning to ACL resource only, I have a proposal for discussion, avoiding the owner problem.
Consider that anyone with Control in root ACL

1. has Control on all pod's acls
2. has Control only if there is no Control access in an acl (this is a fallback not to all situation - the webid in acl might not exist anymore).

[csarven]

There is now a PR that introduces the "owner" concept and requirements: solid/specification#264 . The outcome of that PR should address this issue and be implemented in NSS. The key thing to note here is that owner will have implicit control access to ACL resources. Owner can't remove its own control access or give owner privileges to someone else through ACLs. If the owner wants to perform read-write operations on ACL resources, it will always be allowed. The owner can indeed set authorization policies without allowing itself read-write on a resource. Since it has implicit control, it can always allow itself read-write.

[bourgeoa]

closed with #1604