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

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].