We just had a first occasion of someone with locked account (we set the shell to /bin/true) to log onto our OnDemand instance. And they could log in because their account was still active in the authentication service (campus CAS). They could see the OOD interface, their files, submit jobs, but, the jobs did not work because the compute nodes would log them out (since their shell is /bin/true).
So, we are wondering if you had any thoughts how could we prevent users from also logging to OOD if their authentication still works, but, their shell does not. We’ll be brainstorming that here too.
thanks for making us aware of this. Looknig at the docs, it’s not clear to me what would one put to the “disabled_shell”. The example/default in the docs says disabled_shell: "/access/denied", what does that mean? There’s no file /access/denied.
The idea should be to point to the shell you want to deny access to. So, in the example I believe the string “/access/denied” is trying to convey that idea. So you are disabling the path you hand the setting is the intent i believe.
OK, so if we set it to say “/bin/bash”, the user will be denied accessing bash?
How would that affect the nginx? We already disable the shells by setting the user’s shell to “/bin/true”, our goal is to make nginx aware of that and not start even if the user authenticates with the CAS.
I’d have to check to confirm - but I doubt it. Symlinks may help here - but I’m not quite sure why one disabled user would have true and another false neither are actual shells so I’m not sure what one signifies over the other.
Thanks,it’s OK as it is, but more would add flexibility. We are thinking about doing something else than /bin/true, so, if we do, we’d have to remember to change the disabled_shell to this new value.