UAF hourly restrictions - dynamic?

[Derek Garson]

If a user is already logged in and it is realized that the user is going to be logged in beyond his normal hourly restrictions and such extension is authorized, is there anything that can be done about it?

I had the situation last night when (due to an enormous ....up that would warrant a thread of its own) a large number of users had to work late. (I was at home by then.) I modified them all in UAF shortly before the appointed hour when I realized that we may have a problem but had to watch helplessly while they all got shot down in flames. (This just made a bad situation worse.)

I don't know exactly what they saw on their screens, if anything, but none managed to respond appropriately. (This is perhaps not surprising as none had ever encountered this situation before.)

Anyone care to comment on the implementation of this feature? I might have hoped that before the "kill" takes place the UAF record would be rechecked to see whether it was still appropriate. But apparently not.

V8.3 on Alpha

[Volker Halle]

Derek,

the restricted hours information is read during login and stored in the JIB (Job Information Block) for the process (in JIB$L_PDAYHOURS and JIB$L_ODAYHOURS as a bit vector). As this is only done at process creation time, the change of the UAF is not 'dynamic' for already logged-in processes.

The job controller enforces time restrictions on an hourly basis by scanning all processes and eventually sending a JBC$_RESTRICT broadcast message and triggers process deletion.

If account access restrictions would have been set up differently for primary and secondary days, you might have been able to dynamically switch with SET DAY/SECONDARY.

Volker.

[Jon Pinkley]

As Volker says, it does not appear there is any supported way to change this after the job has been created, for the job tree that was created before the UAF value was changed.

The "best" supported thing, would be to change the UAF, then have the users log out, and log back in. At least then they have control of when their job gets deleted.

I just checked 7.3-2 SSREF and $PERSONA_MODIFY does not offer that as something you can change.

It would be possible to write a $CMKRNL program that diddled the bit vectors, but that isn't something would want to attempt when there is already a bad situation under way (I mean you probably wouldn't want to roll something up from scratch to attempt to fix the problem when you are under duress).

Other options would be using the DELTA debugger, but that isn't for the faint of heart, and the diagnostic messages it provides are quite terse: eh?

Unless there is some reason the users can't log out and back in, because of some long running program, having them logout/back in is by far the easiest/lowest risk solution to the problem.

And you could have issued a $ reply/all/bell "Please logout and log back in, or your process will be automatically killed at 18:00" (or whatever the time was).

You may want to consider "killing" processes with an external process. You will then have a lot more control over what/when it kicks in, and it isn't limited to "on the hour" boundaries.

Jon

[Robert Gezelter]

Derek,

I would agree with Jon. When I encounter such situations, I recommend that management make the decision "before the last coffee break". I then ensure that people logout/login at that point.

Operationally, this is a good practice to establish, as it is also what is needed to voluntarily reconfigure a cluster in the event of a need to switch production to the better functioning system in a cluster.

In a more general context, it also provides a "teachable moment". Operationally, it is not unreasonable to think about the question from the perspective of "when is the deadline for extending past normal closing" (and possibly extending the login window accordingly).

On the OpenVMS Engineering side, I would be inclined to request a documented way in which the "terminate" function can be suspended, and then rescheduled at a particular point in the future. This would allow palliative actions to avoid disruption, in a low-impact way. Changes to reset the information in the JIBs globally would be a larger effort, and would require a deeper impact review. Disabling the Auto-terminate feature using an override would also need to be an auditable event and logged in the security log.

- Bob Gezelter, http://www.rlgsc.com

[John Gillings]

Hi Derek!

I suspect the hourly restriction feature was architected way too long ago, long before anyone had any idea where we would be today. I don't think there are many circumstances (any at all?) where OpenVMS rereads a UAF record after login. I could imagine there all kinds of potential nasties from attempting to "refresh" a process profile after a UAF change.

For the future, you could write your own program to hack the JIB. This is quite easy, and since the field is effectively static, the frequency and nature of use, you could probably bypass the "proper" locking and just blast the fields. Simplest implementation would be to clear the quadword at JIB$L_PDAYHOURS (includes JIB$L_ODAYHOURS). This would turn off any hourly restrictions for that process.

Obviously not supported, or "clean" but maybe acceptable for an extroadinary circumstance?

[Hoff]

Temporarily far closer to when the controls had been minted, the primary and secondary-day mechanism and various other related controls were entirely too weak for any sort of serious use. At best.

I usually went for an idle-process killer (IPK) or terminal timeout program or whatever the related terminology when presented with this, and had created a capable local option to this end. This can range from a simple monitor to a full process control and process management environment.

There are various open-source options here, if you're not into rolling your own process monitor.

[Hoff]

Temporally...

[Derek Garson]

Thanks to all who responded.

A few general comments:

* It was only mentioned in passing to me on the phone that the users were still working and that was with less than 15 minutes before the deadline! Researching the implementation and writing code to run at kernel mode was never going to fly this time.

If it had been 1 hour and 15 minutes before the deadline, I could have tested whether a change to UAF would be dynamic and, finding that it isn't, found some way to contact the users (remotely, spread over a fair area, outside normal office hours).

* An Idle Process Killer or any other Process Killer isn't really a substitute for hourly restrictions. A PK is only reactive. For example, it is likely that the user can login when he is not supposed to and will likely have X minutes before the PK kills him. It could be supplemented by additional enforcement in SYLOGIN but ...

how complex would I want to make it when every day except this one day the VMS hourly restrictions do exactly what I want?

[Derek Garson]

A few specific comments:

Volker, that pretty much covers the implementation.

SET DAY/SEC is not a workaround in this case because the secondary days are even tighter than the primary days.

Investigation suggests that the broadcast didn't "work" because the receiving terminals are specialized devices with narrow screens, set nowrap and running screen-based applications. The message would just have grotted up the screen and at best the computer illiterate user would have seen

%JBC-W-RESTRICT, UAF restricts access at

So it is not surprising that the users did not respond. I could of course catch the broadcast and handle it better.

Jon, yes, the applications are "long running". Login and logout at 2 minutes notice is not an option. However they can suspend and resume - if we could have planned better.

Robert, yes, the incident exposed a procedural hole. We can do better next time.

And, yes, SET DAY/UNRESTRICTED (hypothetical command) would be a good compromise between ease of implementation for Engineering and functionality to me.

John, I agree that rereading UAF would be unusual, particular as it is theoretically a future possibility to create a process with hourly restrictions but no UAF record.