OnDemand does not respond to user group change for disabling applications

[HazelGrant]

https://discourse.openondemand.org/t/ondemand-does-not-respond-to-user-group-change-for-disabling-applications/4029

I've been able to reproduce this.

[johrstrom]

This solution works fine, but only after the user clicks on the “Restart Web Server” link.

I think a restart is expected here. Besides, shouldn't we be caching things for speed? I wonder if the proper guidance here is if you're going to expect everyone to pick up new configs, you should bounce all their puns as the admin.

[stdweird]

we have a cron in place that checks all nginx process for the known groups and compares them with the secondary groups of the owner. and only if they do not match, we kill/cleanup the nginx. user activity will retrigger them with latest group associations.

fyi, this is "normal" linux behaviour for any running process, notthing to do with caching. and it is a security issue in the sense that if you were once in a group, you stay in that group as long as the process is alive. so kicking someone out of the group might still leave them with access.

[serden85]

we have a cron in place that checks all nginx process for the known groups and compares them with the secondary groups of the owner

I found a task "ood" in /etc/etc/cron.d

#!/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
0 */2 * * * root [ -f /opt/ood/nginx_stage/sbin/nginx_stage ] && /opt/ood/nginx_stage/sbin/nginx_stage nginx_clean 2>&1 | logger -t nginx_clean

is this it?

[johrstrom]

I found a task "ood" in /etc/etc/cron.d

That is one that we ship to stop PUNs if they're inactive. @stdweird seems to imply they have their own code to do something different.

[stdweird]

my apologies. yes, we have our own cron to keep our ood backend sane. this is one the things it does.
if interested, i can share it.

[serden85]

Part of the problem was solved. For example, I set the session timeout to 10 minutes (oidc_session_inactivity_timeout: 600) and changed the /etc/etc/cron.d/ood execution interval to once every 10 minutes.
Now, if a session is closed due to inactivity, then after logging in, user’s group membership is updated and thus application availability is controlled.

Do I understand correctly that if it is possible to reduce the execution interval of another cron, then the user’s group membership will be updated directly during the user session?
If so, how can I reduce the execution interval оf another cron?

[johrstrom]

Do I understand correctly that if it is possible to reduce the execution interval of another cron, then the user’s group membership will be updated directly during the user session?

Not 100% sure what you're asking here, but you cannot update a running process (session). You have to restart the process by stopping/killing it then starting it again, thereby getting a new session.

[serden85]

You have to restart the process by stopping/killing it then starting it again, thereby getting a new session

Thanks for the detailed explanation. As I understand it, this happens when the user clicks the “Restart Web Server”.

@stdweird explanation

we have a cron in place that checks all nginx process for the known groups and compares them with the secondary groups of the owner. and only if they do not match, we kill/cleanup the nginx. user activity will retrigger them with latest group associations.

gives me hope that it is possible to automate the process of “Restart Web Server” for a user session.

As a result, I want that after changing the user’s group membership, the “Restart Web Server” event will automatically occur, and it doesn’t matter whether the user’s session is currently active or not.
The question is how to do this?