How does client apps know that certain ACL files cannot be deleted?

[megoth]

The current Web Access Control spec states that you cannot delete the ACL resource for the root container of a user's account.

The root container of a user's account MUST have an ACL resource specified. (If all else fails, the search stops there.)

How does the server indicate to a client application that an ACL resource cannot be deleted?

A way to figure this out today is that the client can check every parent container available if there is a ACL available, but this can be an expensive operation.

[RubenVerborgh]

How does the server indicate to a client application that an ACL resource cannot be deleted?

Could just be a 405 response when you try it.

[megoth]

How does the server indicate to a client application that an ACL resource cannot be deleted?

Could just be a 405 response when you try it.

So there are no way to know it beforehand? E.g. if we want to present a button to the user that allow them to delete the ACL resource. This button should not be presented if they cannot delete the ACL resource anyway.

[RubenVerborgh]

Could be an OPTIONS response with the Allow header.

[megoth]

Could be an OPTIONS response with the Allow header.

That I think is a good solution.

Would we specify that behavior in the specification?

[RubenVerborgh]

+1 from me

[dmitrizagidulin]

I think it'd be really helpful for us to be able to denote certain resources as "protected", or ones that like, require a confirmation step or something, to delete. I can think of 3 resources that basically lock out the user from the account - the root .acl, the profile /card, and (distantly) the root .meta file (which is where the account recovery email is kept for some reason).

[kjetilk]

@dmitrizagidulin Yeah, I agree very much. I voiced similar ideas, we basically need to have some sort of "hey, be careful, if you're sure, do foo" :-) Could you be bothered to detail your thoughts about it in a separate issue?

[dmitrizagidulin]

@kjetilk - Just to double check, why a separate issue? Isn't that what we're talking about in this issue? (I could totally be misinterpreting :) )

[csarven]

In response to the original post, and just to throw complexity to this issue - we love complexity right right? -... why can't all resources (including ACLs) be deleted by an app with an authorized agent?

What I'm sensing is that by preventing "certain" resources from getting deleted, it enforces alternative ways to actually get to delete them. That's not necessarily a simpler, cheaper, or secure way, but just moves the responsibility elsewhere.

So, I like ideas that Dmitri shares re protected resources, confirmation steps etc. It immediately makes me think of a user in the sudo group that tries to delete a read-only file. Some systems, like Debian (and friends) for instance, say "remove write-protected regular file 'foo'?"

I'm sure a lot of energy went into agreeing and implementing that for nix, so, I can only +1 that idea because for the short to mid-term, that's going to let us bypass reinventing and potential headaches.

We should also factor in how this plays out if/when a "locking mechanism" (like WebDAV's) is part of or extended in the Solid system.

[kjetilk]

@dmitrizagidulin :

@kjetilk - Just to double check, why a separate issue? Isn't that what we're talking about in this issue?

I'm taking this issue fairly literally :-) So, I take the original question as the one that this issue should address, i.e., how the client can tell if it will not be able to delete a resource, and a good solution to that is the proposed use of the Allow header. I think that when this is speced, it will address this issue.

But it remains a bigger issue, that there are certain resources that the user should be alerted about that may have larger effects than they anticipate, and probably verification of that intent. And that's how I interprete your comment too :-)

[megoth]

Just noting some resources that are related to this issue (via @dmitrizagidulin):

• https://github.com/solid/solid/issues/27
• https://github.com/solid/node-solid-server/issues/1289
• https://github.com/solid/solid/issues/130#issuecomment-287849451
• https://github.com/solid/solid-spec/issues/168

[kjetilk]

Also see #44 .

[csarven]

I think this issue is a special case of the general case in https://github.com/solid/specification/issues/171 . See https://github.com/solid/specification/issues/171#issuecomment-627003773 for summary on Allow, WAC-Allow, Link approaches. dokieli also shares the general use case: https://github.com/linkeddata/dokieli/issues/96 , https://github.com/linkeddata/dokieli/issues/137 (which triggered 171).

The link relation to root container's ACL will only be exposed if agent has Control on the root container. Hence, the discovery of the ACL resource starts from the root container.

With the exception of disallowing the deletion of root container's ACL, authorized agents can potentially delete any ACL.

Unauthorized agents will simply be denied (401/403/404 being discussed) from knowing whether an ACL resource at a particular URL exists in the first place (even if say the requester knows it as a fact based on out of band knowledge).

For authorized agents, the Allow header on root container's ACL is sufficient ie. it would simply omit DELETE.

For authorized agents, while WAC-Allow can indicate Control and Write (whether on the ACL itself or on the root container), it can't additionally express delete is disallowed given the special case about root container's ACL.