FileExplorer: Allow user to chmod files.

[brianmcmichael]

Currently cloudcmd displays file permissions, but does not allow you to change them.

I've submitted an issue at coderaiser/cloudcmd#63

Additionally, node.js uses default file permissions of 0666 for uploads. This is unacceptable and will need to be changed to a default of at least 0644.

┆Issue is synchronized with this Asana task by Unito

[brianmcmichael]

That second part of this is now it's own issue at: OSC/ood-fileexplorer#12

[brianmcmichael]

I have been added to a new project on the cloudcmd org to come up with a solution for this.

https://github.com/cloudcmd/file-mode

[brianmcmichael]

Further research reveals that node.js uses 0777 for new folders and 0666 for new files.

I've confirmed that this is the current behavior of cloudcmd. Both in folder creation and file uploads. (A file with permissions of 0600 was uploaded and the node process remapped it to 0666.)

Node.js provides a process.umask(mask) method that will trim down these default permissions.

Further experimentation will be required to see if I can run a global mask on the process or if I will need to invoke the mask at each file/folder creation event.

This link for my reference: http://x-team.com/2015/02/file-system-permissions-umask-node-js/

[brianmcmichael]

This appears to be a result of Passenger (or nginx) wiping the user environment.

Tests of Ruby code in the new passenger infrastructure reveal similar results.

File.umask = 0
FileUtils.mkdir_p creates a new directory with permissions 0777
FileUtils.touch creates a new file with permissions 0666

Jeremy's tests of file and folder creation in the console did respect the system umask settings, so this issue may be able to be resolved by resetting umask in passenger to 0022.

[brianmcmichael]

Loading an app after navigating to websvcs08.osc.edu:5000/nginx/stop sets the app umask at 022

Loading an app after navigating to websvcs08.osc.edu:5000/nginx/reload sets the app umask at 0

The difference appears to be whether passenger is running as a separate process from nginx (after stop) or as a child process of nginx (after reload)

[nickjer]

Or both the "child process" and the "umask" issues could both be caused some underlying mechanism that occurs when you run sudo nginx -s reload.

[johrstrom]

This is still very much relevant and indeed related to #2609.