Re: Trigger state: *DISABLED -- what the heck is that, and from whatOS revision, and what do I do about it?

Jim Franz wrote:

To determine if *disable is useful in triggers, stop thinking like a one person shop, and consider the separation of duties.
If I'm the programmer, I can create applications that add/remove triggers.
For security, I would want CRTPFTRG to be completely locked down, and only usable in the install of software.
The operations staff should only control whether they are enabled or disabled, and then only with good auditing.
CRTPFTRG could be a powerful tool for cracking.

CRTPFTRG? DLTPFTRG? Never heard of those, either. Are they anything like ADDPFTRG and RMVPFTRG?

;-)

At any rate, I would argue that the ability to disable a trigger without removing it, precisely because it DOESN'T show up in a PRTTRGPGM report, makes CHGPFTRG more dangerous than ADDPFTRG or RMVPFTRG. So much so that I would say that it's the first example I've ever encountered of an OS revision from IBM that CREATED a security hole, rather than REMOVING one.

Think about it: you have a trigger program that, instead of just propagating data, enforces some business rule. Maybe even one required for compliance with the law. Somebody with a priv'd account and malicious intentions goes in and quietly disables the trigger. Suddenly, changes that would ordinarily be vetoed can sail right through, and yet the only way anybody would notice that the trigger isn't getting invoked would be if they either (1) did a WRKOBJLCK on the trigger program, or (2) did a DSPFD on the file, things they wouldn't do unless they suspected that the trigger was being bypassed, strongly enough to disbelieve what the PRTTRGPGM report says.

--
JHHL