My memory is those limits apply to the per-user side of things, so you would need to restart your account’s service using the ood web page by clocking on the “?” icon in the upper right, and selecting “restart web services”. That will restart all the processes running as “you”, which should cause the new settings to be picked up.
First - noone welcomed you, so let me do that now. Welcome!
Secondly - I think you actually want to take a look here and disable the file app altogether for some users by use of file access control lists on the Files app. This means that entire app is disabled for those users (upload, download and browse).
That said - you should know that Open OnDemand (OOD) respects the underlying file permissions. That is users using OOD who can’t see restricted files in a shell due to permissions and so on, won’t be able to view the files in the web through OOD either. OOD does not give privilege to the users they don’t already have. Indeed it runs as the user with their UID and GID(s). So if they for example can’t write to a directory through a shell - they won’t be able to upload the file through OOD.
So the whole issue may be moot if the files you’re restricting are indeed restricted to those users.
We at OSC have protected data locations (for HIPPA data and so on) and they’re access limited through group permissions along with being monitored for access & modification.
An ood server reboot will restart everything. The “restart services” restarts your account’s nginx instance which is handy when you’re testing but don’t want to do a server reboot… Depending on limits you’re trying to achieve, the /etc/ood/nginx.yml file may offer other settings. For example, see the block for “nginx_file_upload_max” in that file.
@jeff.ohrstrom Your suggestion is perfect for our use case. After doing chmod 700 /var/www/ood/apps/sys/files/ the Files app is no longer visible in the webui which is exactly what I needed. Actually I can adjust permissions so only members of group of “data-managers” can access the Files app in the webui, which is perfect for our use case.
@azric the option to set the value to 1 works as it limits the upload to 1B
@firstname.lastname@example.org I did a check on the apps filtering and although changing the permissions to say 700 for the /var/www/ood/apps/files and /var/www/ood/apps/file-editor folders, ood will hide the apps from the dashboard however you can still access those by directly entering their url:
https://example.com/pun/sys/dashboard/ works as expected and I don’t see the option for Files, but if I edit the url to https://example.com/pun/sys/files I end up in the Files app: https://example.com/pun/sys/dashboard/files/fs/<path/to/my/home>, I can then even edit files.
Is there something else that should be configured? or maybe this does not work for the main apps? I can imagine disabling the files app might break the myjobs app at least?
Ah you are right, if I also change the permissions of manifest.yml then the https://example.com/pun/sys/files url leads to a Not Found message. So it seems that the issue is with:
So the check bypases the folder permissions and just checks the target file I think, I did a quick test by changing the line to: app_dir.directory? && app_dir.readable? && app_dir.join('manifest.yml').readable?
And it seems to do the trick, but I’m not sure if this is the proper fix…