Bug #84554

User that has NO permission in group to delete files or folders in FAL can delete files and folders anyway

Added by Angelo Previtali over 1 year ago. Updated 7 months ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
-
Start date:
2018-03-29
Due date:
% Done:

0%

TYPO3 Version:
8
PHP Version:
7.1
Tags:
Complexity:
Is Regression:
Sprint Focus:

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!

be-ansicht-gruppe-redaktoren.png View (9.43 KB) Angelo Previtali, 2018-03-29 11:17

redaktoreneinstellungen.png View (8.94 KB) Angelo Previtali, 2018-03-29 11:18

fileadmin-icons.png View (10 KB) Angelo Previtali, 2018-03-29 11:21

permissions-folder-files.jpg View - File/Folder properties in fileadmin (201 KB) Angelo Previtali, 2018-05-16 09:22

permissions-folder-files.jpg View (198 KB) Angelo Previtali, 2018-05-16 09:25

Annotation 2019-03-06 143053.png View (72.7 KB) Susanne Moog, 2019-03-06 14:31


Related issues

Related to TYPO3 Core - Bug #85425: Check the copy permissions correctly Resolved 2018-06-28

History

#1 Updated by Angelo Previtali over 1 year 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

#2 Updated by Angelo Previtali over 1 year 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.

#3 Updated by Guido Schmechel over 1 year 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.

#4 Updated by Angelo Previtali over 1 year 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

#5 Updated by Angelo Previtali over 1 year 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.

#6 Updated by Riccardo De Contardi over 1 year 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

#7 Updated by Angelo Previtali over 1 year 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.

#9 Updated by Angelo Previtali over 1 year 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 :)

#10 Updated by Riccardo De Contardi over 1 year 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

#11 Updated by Angelo Previtali over 1 year ago

Are there some news concerning this issue? Will this be fixed somehow and somewhere?

#12 Updated by Guido Schmechel over 1 year ago

  • Related to Bug #85425: Check the copy permissions correctly added

#13 Updated by Susanne Moog 7 months ago

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).

#14 Updated by Angelo Previtali 7 months 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" 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).

Checked in 8.7.24 and 9.5.5 > works. Thx

You can close this ticket.

#15 Updated by Riccardo De Contardi 7 months 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.

Also available in: Atom PDF