owncloud
User doesn't get correct message if he creates resource with same of denied resource name
3.0.0-rc.3+9945dad64 7.0.0-rc.36
Steps:
- create project space with folder "New folder"
- share space to einstein
- deny "New folder" for einstein and ensure that einstein doesn't see folder in the space
- enstein tries to create folder "New folder"
Expected:
if we talk about default folder name I would suggest give to user first:
give error message that folder name is exist. @tbsbdr probably can say correct message
Actual: 405 Method Not Allowed user gets error without an explanation of what happened
give error message that folder name is exist.
Actually we can't do that because it would leak information about the existence of the folder to the user, which they should not know about. IMO the current message "Failed to create folder" is fine for now. @tbsbdr @kulmann Thoughts?
Yes, thought about that as well... we must not leak the info that the folder exists.
Whatever happens, the existence of the folder is leaked (to some extent - depending how "smart" the user is)
With the current UI, the user can create a few folders "folder1", "folder2"... and knows that they are able to create new folders. Then they try to create "New folder" and get some message or error or whatever and the folder is not created. If they understand the roles/permissions framework of spaces, then they know that the reason that they cannot create the folder must be that it already exists. So if they suspect that there might be some secret folder, they can keep trying to create folders with various names. Eventually they might try the name "Secret-project-with-American-agency" and they will be able to deduce that such a folder already exists. And discovering the folder name might reveal some information that they should not know.
Actually, users who have strict security needs should not put "secret" data embedded in folder or file names.
I can't think of a way of implementing this sort of roles/permissions framework without having the potential for such leaks.
Actually, users who have strict security needs should not put "secret" data embedded in folder or file names.
I can't think of a way of implementing this sort of roles/permissions framework without having the potential for such leaks.
Yes, agreed. I think the most important use case of the denial is: invite a group to a space, but exclude users x, y and z. This way the entire space will not be visible to users x, y and z.