Revert "Set umask before operations that create local files"

[bgottschall]

This reverts the pull request #25280, 'fixing' undescribed issues with "other php stuff". It actually forces folder and file permissions on all files created by nextcloud from within the PHP code which should violate common coding standards in my opinion.

The merge completely ignores the umask from the system that is set by an administrator for various reasons. Just by mentioning one example when someone uses an external folder over the external files plugin, nextcloud will create folder and files there without the group having write permissions which breaks with many NAS setups e.g. Unraid (#29041).

Instead of fixating the servers file and folder permissions within nextcloud ignoring settings carefully chosen by the administrator, the "other php stuff" should be fixed.

Fix #29041

[solracsf]

What about #29041 (comment) instead of just reverting? 🤔

[bgottschall]

What about #29041 (comment) instead of just reverting? thinking

This comment only takes the group and other permission portion of the umask and forces the owner umask to 0. While it make sense from the nextcloud perspective to make sure that it always has read/write permissions on the files it creates it is a unecessary change to begin with. A process umask is set by whoever starts it (systemctl service e.g.) which is typically 022.
If a system administrator chooses a different mask he should be allowed to and nextcloud should not change it. If the administrator chooses a mask that crashes with nextcloud, it is a configuration problem and it should not be nextcloud task to alleviate this potential wrong doing. One could add in the adminstrator documentation that nextcloud expects a umask that preserves read/write permissions of files and folders, but hardcoding this safeguard into the php code?

Edit: And I want to add that it is totally unclear what this merge fixed in the first place.

[bgottschall]

I've removed the chmod inside mkdir, which is a line that is also not necessary.

Referring to the PHP doc https://www.php.net/manual/en/function.mkdir.php mkdir respects the umask of the system, meaning the folders are created with the 755 permissions if the umask is 022 for example. Another aspect is that mkdir is called with recursive set to true. Setting only the last directory using chmod is incomplete as all parent directories that might have been created would not be affected.

[come-nc]

Maybe we could add a check in https://github.com/nextcloud/server/blob/master/apps/settings/lib/Controller/CheckSetupController.php that checks the umask? But maybe this is not possible if umask can be set differently in each storage or folder, not sure.

[bgottschall]

Maybe we could add a check in https://github.com/nextcloud/server/blob/master/apps/settings/lib/Controller/CheckSetupController.php that checks the umask? But maybe this is not possible if umask can be set differently in each storage or folder, not sure.

The umask is a process configuration (not folder or storage related), however the process can change its umask at any given time. That means php code (apps/extensions) could change the umask simply with umask(...). I don't see a reason why they ever should do that and if, they should fix it there or revert it back to the process default after being finished.
Though if one changes the umask in the php code, it will only be changed for the local execution context and the next request starts with the process default again.

[come-nc]

Maybe we could add a check in https://github.com/nextcloud/server/blob/master/apps/settings/lib/Controller/CheckSetupController.php that checks the umask? But maybe this is not possible if umask can be set differently in each storage or folder, not sure.

The umask is a process configuration (not folder or storage related), however the process can change its umask at any given time. That means php code (apps/extensions) could change the umask simply with umask(...). I don't see a reason why they ever should do that and if, they should fix it there or revert it back to the process default after being finished. Though if one changes the umask in the php code, it will only be changed for the local execution context and the next request starts with the process default again.

So if it is the same for the whole process we can test it in CheckSetupController and warn if it is a mask that will cause problem (if it will disallow editing what we create). Ideally with a link to the documentation about this.

[bgottschall]

Maybe we could add a check in https://github.com/nextcloud/server/blob/master/apps/settings/lib/Controller/CheckSetupController.php that checks the umask? But maybe this is not possible if umask can be set differently in each storage or folder, not sure.

The umask is a process configuration (not folder or storage related), however the process can change its umask at any given time. That means php code (apps/extensions) could change the umask simply with umask(...). I don't see a reason why they ever should do that and if, they should fix it there or revert it back to the process default after being finished. Though if one changes the umask in the php code, it will only be changed for the local execution context and the next request starts with the process default again.

So if it is the same for the whole process we can test it in CheckSetupController and warn if it is a mask that will cause problem (if it will disallow editing what we create). Ideally with a link to the documentation about this.

Added a check, would appreciate if somebody could take over the frontend including testing as my setup doesn't allows testing currently and I haven't touched anything on the frontend yet.

[bgottschall]

A bit unfortunate that this is not moving forward. I mean there is a missing frontend message of the umask server check but this pull request is mainly about removing faulty code not introducing something new in the server.

[PVince81]

obsoleted by #32723