Bug #84554
closed
User that has NO permission in group to delete files or folders in FAL can delete files and folders anyway
0%
Description
By setting up a storage and a brandnew user and removing the group the permission to just READ files and NOT to delete those the user can delete files or folders anyway. That shouldn't be!
I tried it to set it in the BE user group 
and by deny him the permissions in the files and folder permissions by disable this on
plus adding the PageTS Script to disallow him to deny the user on the shared storage (i.e. the storage 1)
permissions.file.storage.1 {
addFile = 1
readFile = 1
writeFile = 0
copyFile = 0
moveFile = 0
renameFile = 0
unzipFile = 0
deleteFile = 0
addFolder = 0
readFolder = 0
writeFolder = 0
copyFolder = 0
moveFolder = 0
renameFolder = 0
deleteFolder = 1
recursivedeleteFolder = 0
}
But afterthat the user is still able to DELETE files and folders everywhere!
The set upped permission seems not to work at all! No matter what you set as permissions - nothing works!
Files
Updated by Angelo Previtali about 6 years ago
- Subject changed from User that has NO permission in group to delete files or folder in FAL can delete files and folders anyway to User that has NO permission in group to delete files or folders in FAL can delete files and folders anyway
Updated by Angelo Previtali about 6 years ago
Are there any news concerning this issue? It would be great if anyone could anser me just to know what priority this bug has.
Thanks.
Updated by Guido Schmechel almost 6 years ago
Hi Angelo, I could not reproduce this in the current master (9.3-dev). Are you sure you have set the user permissions? These are almost all unlocked by default. This will overwrite the group settings.
Updated by Angelo Previtali almost 6 years ago
Hello Guide
currently I need it on a 8.7.13. Can you retry it on a 8.7.13 (or a 8.7-branch?). If on the editor group i locke every thing for deleteing it the editor STILL has all the rights to delete files.
Thanks for helping me out of this (or better) fixing it.
Regards,
Angelo
Updated by Angelo Previtali almost 6 years ago
Tried on a 9.2.0 - same results. Even if a editor has NO RIGHTS to delete files HE CAN. Same as on a 8.7.
Updated by Riccardo De Contardi almost 6 years ago
Did you use usergroup permissions or user permissions?
How are the user permissions set?
I think that the problem here is: how should we interpreter the user permissions against the usergroup permissions? Is it a sum or a replacement? I hope I've made myself clear
Updated by Angelo Previtali almost 6 years ago
I used USERGROUP permissions to set up the file permissions, right. This isn't working. Why? It should, right? Any hint?
Even if a set permissions on a USER the permissions for the files arent't working.
Mycase is: The USER (in the usergroup) has NO access to delete, modify, etc.) any files or folders. The USERGROUP has ALSO NO acceess to do the same thing. So this must be a bug.
Updated by Angelo Previtali almost 6 years ago
Updated by Angelo Previtali almost 6 years ago
Ok. I tested something and now it seems that all the icons to delete, replace, modifiy, etc. are away (THX to Riccardo De Contardi for the hint!).
BUT now HOW can the properties on the singles files/folders be adapted? See printscreen below.
Even if the USER and the USERGROUP has NO access to do anything then READ files the properties on a file/folder are still here. He still can delete, rename, copy, etc. those files.
Still a bug :)
Updated by Riccardo De Contardi almost 6 years ago
ok so there is a problem with the context menu; I don't currently remember if there is already an open issue.
About my previous note about the consistency of user/usergroup permissions I have already put a comment here to explain my point of view #76273
Updated by Angelo Previtali almost 6 years ago
Are there some news concerning this issue? Will this be fixed somehow and somewhere?
Updated by Guido Schmechel almost 6 years ago
- Related to Bug #85425: Check the copy permissions correctly added
Updated by Susanne Moog about 5 years ago
- File Annotation 2019-03-06 143053.png Annotation 2019-03-06 143053.png added
- Status changed from New to Needs Feedback
I cannot reproduce this on v9/master. My setup:
- Usergroup with Files "Read" and Directory "Read" permissions
- User with that UserGroup and explicit set Files "Read" and Directory "Read" permissions
Result:
- User can see folders and files in storages but context menu and extended view only contain "Info" and "Copy" - no delete or rename stuff - see screenshot (note the lock on the folders, too).
Updated by Angelo Previtali about 5 years ago
Susanne Moog wrote:
I cannot reproduce this on v9/master. My setup:
- Usergroup with Files "Read" and Directory "Read" permissions
- User with that UserGroup and explicit set Files "Read" and Directory "Read" permissionsResult:
- User can see folders and files in storages but context menu and extended view only contain "Info" and "Copy" - no delete or rename stuff - see screenshot (note the lock on the folders, too).
Checked in 8.7.24 and 9.5.5 > works. Thx
You can close this ticket.
Updated by Riccardo De Contardi about 5 years ago
- Status changed from Needs Feedback to Closed
- Target version deleted (
Candidate for patchlevel)
@Angelo Previtali Thank you for your quick reply;
Closing this issue as requested by the reporter.
If you think that this is the wrong decision or experience the issue again please reopen it or ping me.