2 May
2019
2 May
'19
9:40 a.m.
On May 2, 2019, at 10:49 AM, Ethan Dicks
<ethan.dicks at gmail.com> wrote:
On Thu, May 2, 2019 at 8:13 AM Paul Koning <paulkoning at comcast.net> wrote:
Thinking back 35 years... it was that someone enabled the backup
operator account with SETPRI, allowing the operator to elevate the
priority of the script. What I think was happening was that the
script was grabbing buffers from the disk before they were filled and
slamming them out to tape. It definitely cut minutes off the backup
time, which is why it happened.
I'm sure the VMS wizards hadn't expected a user process to run at
priority 31 (IIRC) because anyone with SETPRI _surely_ had the wisdom
not to elevate above system processes.
Definitely a failure to think of ways users could abuse the system.
-ethan
More in particular, it is a design failure, relying on timing hacks rather than explicitly
and correctly passing ownership of data from producer to consumer.
paul
On May 1,
2019, at 10:58 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
I think those were still true for V3.X. I know we had a problem back
then with our backups where someone elevated the priority of the Tape
ACP over the Disk ACP (because it was faster) that left us with months
of corrupt backups.
Wow, that reflects very badly on the engineering involved. Setting priorities wrong
might cause things not to get done, or to take too long, but it cannot ever be an excuse
for data corruption.