Bug #70812

edit user or usergroup > cannot remove every permission on file/directories

Added by Riccardo De Contardi about 6 years ago. Updated over 1 year ago.

Status:
Accepted
Priority:
Must have
Assignee:
-
Category:
Backend User Interface
Start date:
2015-10-17
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
8
PHP Version:
5.6
Tags:
Complexity:
Is Regression:
Yes
Sprint Focus:

Description

Steps to reproduce:

1) System > backend user module (or root > list)
2) click + to create a new user
3) remove EVERY permission
4) on the tab "Mounts and workspaces" > "Fileoperation permissions:" uncheck everything both on "directory" and "files" list.
5) save
Result: "directory" and "files" lists still have checked options (the one you unchecked before) that is:

Directory: Read
Directory: Write
Directory: Add
Directory: Rename
Directory: Move
Directory: Delete

Files: Read
Files: Write
Files: Add
Files: Rename
Files: Replace
Files: Move
Files: Delete

(see attached file)

- you have to remove EVERYTHING from both to have this situation: if you keep at least one setting in one of the lists, the result is saved and not reverted
- this issue does not seem present on 6.2.15


Files

Schermata 2015-10-17 alle 17.12.39.png (52.7 KB) Schermata 2015-10-17 alle 17.12.39.png Riccardo De Contardi, 2015-10-17 17:18

Related issues

Related to TYPO3 Core - Bug #71020: Backendgroups / Rights for fileoperationsClosed2015-10-26

Actions
Related to TYPO3 Core - Bug #76033: Invalid default value for be group/user file permissionsClosedMarkus Klein2016-05-03

Actions
Related to TYPO3 Core - Bug #77705: No observance for the permissions for fileoperationsClosed2016-08-31

Actions
Related to TYPO3 Core - Bug #77704: Permissions for fileoperationsClosed2016-08-31

Actions
Related to TYPO3 Core - Bug #80279: Default language can't be selected/storedNew2017-03-14

Actions
Related to TYPO3 Core - Bug #65573: File operation permissions are not correctly inherited from group when field in user is NULLClosed2015-03-06

Actions
Related to TYPO3 Core - Bug #88312: User group definitions not saved properlyClosedAndreas Fernandez2019-05-09

Actions
Related to TYPO3 Core - Bug #89643: file permissions cannot not both be emptyClosed2019-11-11

Actions
Has duplicate TYPO3 Core - Bug #76035: Unable to remove all directory and file permissions for be users or groupsClosed2016-05-03

Actions
Has duplicate TYPO3 Core - Bug #81506: formEngine: fileoperation permissions not possible to persist if no permission ist selectedClosed2017-06-07

Actions
#1

Updated by Riccardo De Contardi about 6 years ago

  • Subject changed from create a new user > cannot remove every permission on file/directories to edit user or usergroup > cannot remove every permission on file/directories

the issue affects also usergroups, not only users. See also #71020

#2

Updated by Riccardo De Contardi almost 6 years ago

This issue is still valid for the latest 8.0-dev master

#3

Updated by Markus Klein over 5 years ago

  • Status changed from New to Accepted
  • Priority changed from Should have to Must have
  • Target version set to Candidate for patchlevel
  • Sprint Focus set to Stabilization Sprint
#4

Updated by Daniel Windloff about 5 years ago

I had the same problem on an own TCA configuration.
I think this bug has the following reason:

In

typo3/sysext/backend/Classes/Form/Element/SelectCheckBoxElement.php
line 114 the default value for an empty list is defined as "".
$html[] = '<input type="hidden" class="select-checkbox" name="' . htmlspecialchars($parameterArray['itemFormElName']) . '" value="">'; 

In

DataHandler::castReferenceValue
the value "" would be replaced by the default value defined in TCA.

Changing the return of castReferenceValue or the default value could be breaking change in some scenarios.

#5

Updated by Frans Saris about 5 years ago

  • Is Regression changed from No to Yes
#6

Updated by Riccardo De Contardi over 4 years ago

Still affects both 7.6.15 and the latest master.

#7

Updated by Josef Glatz over 4 years ago

  • Has duplicate Bug #81506: formEngine: fileoperation permissions not possible to persist if no permission ist selected added
#8

Updated by Josef Glatz over 4 years ago

  • TYPO3 Version changed from 7 to 8
  • Sprint Focus deleted (Stabilization Sprint)

8LTS and 9-dev (master) still affected

#9

Updated by M S about 4 years ago

Thats a really hard bug since a few years. Would be nice if somebody could fix this.

#10

Updated by Markus Klein about 4 years ago

I took a look already some time ago. It is also super hard to fix this!
I wasn't yet able to figure out if this would result in a major breaking change of DataHandler.

#11

Updated by M S about 4 years ago

Markus Klein wrote:

I took a look already some time ago. It is also super hard to fix this!
I wasn't yet able to figure out if this would result in a major breaking change of DataHandler.

Would it be able to add a temoporary checkbox like "no permissions"?

#12

Updated by Riccardo De Contardi almost 3 years ago

  • Related to Bug #80279: Default language can't be selected/stored added
#13

Updated by Susanne Moog over 2 years ago

  • Related to Bug #65573: File operation permissions are not correctly inherited from group when field in user is NULL added
#14

Updated by Robert Wildling over 2 years ago

  • Related to Bug #88312: User group definitions not saved properly added
#15

Updated by Riccardo De Contardi almost 2 years ago

  • Related to Bug #89643: file permissions cannot not both be empty added
#16

Updated by Riccardo De Contardi almost 2 years ago

As reported by on #89643 from Robert Wildling, this issue still affects TYPO3 9.5.x

#17

Updated by Riccardo De Contardi over 1 year ago

Still present on latest master (10.4.0-dev)

#18

Updated by Riccardo De Contardi over 1 year ago

I was thinking: the issue is still present, but... does it make sense to remove every permission from the file or directory operations? If I don't want let a group do anything on a filemount - not even read it - I should not give it to the group, am I right? I hope I explained myself.

Or is there some scenario that I am not considering?

My suggestions

1) Make the "Read" always checked and readonly - later we can even remove it from the view maybe.
I think that this would even prevent some "odd" config like Read: deny; Write: allow

or

2) print out an error or warning message if I try to remove everything and save (It could even be something like "you can't remove every permission from the directory / file; permissions reverted to the previous selection"

#19

Updated by Jonas Eberle over 1 year ago

I think 1) is a very practical choice.

#20

Updated by Felix Rauch over 1 year ago

Riccardo De Contardi wrote:

I was thinking: the issue is still present, but... does it make sense to remove every permission from the file or directory operations? If I don't want let a group do anything on a filemount - not even read it - I should not give it to the group, am I right? I hope I explained myself.

Or is there some scenario that I am not considering?

Well not technically in this case, but doesn't the underlying Form Engine issue still exist?

I remember wrangling this issue for a while with a project because the requirements stated some form should have a multi-checkbox list with default selection and possibility to select nothing.

I think if this issue would be closed with a workaround, the TCA documentation should be adjusted to give some indication that the behaviour I described is out of spec for that field type (which I could understand, the underlying issue is a nightmare to fix, at least it was when I attempted some years back)

#21

Updated by Riccardo De Contardi over 1 year ago

@Felix Rauch I got your point, you are right;

I feel that multiple checkboxes on FormEngine are a bit misfortunate; there is another issue: it is not possible to mark them as required ;)

Anyway, so there are two separate issues here

- the technical one about FormEngine and multiple checkboxes
- the conceptual one about permissions on files and folder

Also available in: Atom PDF