Add functionality to globally disable the terminal app for OOD Install.

[gerald-byrket]

Add functionality to globally disable the terminal app for OOD Install.

https://discourse.openondemand.org/t/disable-terminal/2212/2

┆Issue is synchronized with this Asana task by Unito

[treydock]

That's super easy.

chmod 0700 /var/www/ood/apps/sys/shell

If the user can't read the app, it won't be available. We make heavy use of this at OSC to disable some apps for sites like class.osc.edu.

[tdockendorf@web05 ~]$ ls -la /var/www/ood/apps/sys/
total 60
drwxr-xr-x 15 root root 4096 Jun 23 16:12 .
drwxr-xr-x  5 root root 4096 Jun 23 16:12 ..
drwx------  3 root root 4096 Jul 12 09:02 activejobs
drwxr-xr-x  4 root root 4096 Jul 12 09:02 bc_classroom_jupyter
drwxr-xr-x  4 root root 4096 Jul 12 09:03 bc_classroom_rstudio
drwx------  3 root root 4096 Jul 12 09:02 bc_desktop
drwxr-xr-x  4 root root 4096 Jan 21  2021 bc_osc_iqmol
drwxr-xr-x  4 root root 4096 Feb 18 16:35 bc_osc_jupyter_spark
drwx------  4 root root 4096 Dec 22  2021 bc_osc_paraview
drwxr-xr-x  4 root root 4096 Jul  6 09:46 bc_osc_qgis
drwxr-xr-x 14 root root 4096 Jul 12 09:02 dashboard
drwxr-xr-x  3 root root 4096 Jul 12 09:02 file-editor
drwxr-xr-x  3 root root 4096 Jul 12 09:02 files
drwx------ 14 root root 4096 Jul 12 09:02 myjobs
drwxr-xr-x 10 root root 4096 Jul 12 09:02 shell

[gerald-byrket]

cool. if changing the perms is an acceptable answer, then i'll pass that on to the guy in the discourse, or if you want to that is fine as well.

[treydock]

Left comment on Discourse. Changing permissions is the most reliable and secure way to block access.

[gerald-byrket]

I'm re-opening this. We should have this as an option. Jesse is correct when he states, "If they have button, they will click it and if it errors, thats a ticket."

[treydock]

I can't reproduce that issue on any OSC systems. We can't make it an option because it requires root privileges , the option is changing permissions, that's how OnDemand has always worked. If you can reproduce, please post reproduction steps.

[treydock]

So one reason we have never made these options, is security. We do NOT want OnDemand acting to enforce permissions or access, we rely on other things to do that (Apache, POSIX, Linux, etc). That's one reason we are moving away from cluster YAML having ability to define ACLs and instead relying on POSIX ACLs, it's more secure as we don't rely on our code to enforce security we instead rely on well established technology like Linux POSIX ACLs. Doing anything inside of OnDemand code to enforce any kind of access controls is going to make OnDemand less secure.

[gerald-byrket]

Thanks @treydock . I'm going to leave this open for further discussion.

[Oglopf]

I'm unsure if this is as simple as copying the pattern we used in the Files App and just including something in the configuration_singleton as a bool to just not have the terminal button render in those various views by checking Configuration.<app>_enable_shell_button and only render on true.

Or maybe even a global in the configuration_singleton to just not allow the button to ever render? Some thoughts to avoid any serious changes beyond just never showing the option to the user in the UI.

[treydock]

See my comment in Discourse, there is a way to make the "Connect to " go away, we had to implement that change to avoid jobs thinking they could SSH into Kubernetes nodes which isn't possible. I'm not sure where else besides job cards the terminal button might show up. For the actual Shell app, permissions are preferred way to get rid of the app but that won't get rid of the various SSH buttons.

https://osc.github.io/ood-documentation/latest/customization.html#disable-host-link-in-batch-connect-session-card

[treydock]

Looks like the link I gave plus that Files App Singleton would combine to solve the issue. I'll pass on the documentation link via Discourse.

https://osc.github.io/ood-documentation/latest/reference/files/ondemand-d-ymls.html?highlight=files_enable_shell_button