Re: Trigger programme without a trigger.

Joe Pluta wrote:

David Gibbs wrote:

here's a big difference between 'accidental' and 'malicious'.

No there's not. Not when it comes to the end result. If you can't control which users have access to which profiles, then you have ZERO security. Period. I don't care whether it's malicious or accidental, the damage is the same.

Well obviously if someone is making such a change they need to have the appropriate authorities ... and if they have the appropriate authorities then they should be experienced enough to know what they are doing.

If someone has the authority to, and goes to the effort of, removing the trigger (which can't be done unless they can get exclusive access to the file) then their actions are clearly not accidental.

Disagree. Somebody could accidentally remove a trigger just by thinking they're doing it in test. If they're clueless enough to run with the wrong authority, chances are they're clueless enough to run with the wrong library list, no?

Then the person clearly doesn't have enough experience to be granted the authority.

If you're running a test, then you should be using a profile that doesn't have authority to production. Anything else is just plain stupid.

This isn't even a system security of application architecture issue ... it's an organizational problem.

That's the problem with trying to prevent stupidity. You can't.

Of course you can't ... but you can prevent ACCIDENTS.

No it's not. If you design your system correctly so that only certain profiles can access certain things, that's called security. It's sort of the point of the whole process. And if you design your database so that only a single user can update it, then that's called database security, and it's a good thing.

In a heterogeneous environment, this doesn't fly. The idea that only one user on one system can update a database is a thing of the past.

IMO, trigger programs are a fine way to enforce business rules in heterogeneous environments.

It's an approach, certainly. Personally, I give it one and a half stars, because to really put in business rules, you have a lot of overhead, and the overhead can't be removed when needed - for say, a file copy or a mass update.

Sure it can ... put a flag in your trigger program that turns off the logic ... yes, the trigger fires, but the logic is bypassed. Obviously the flag source needs to be secured so the logic can't ACCIDENTALLY be turned off.

Unless of course, you have a way to remove the trigger programatically. Of course, the program that removes the trigger could be run "accidentally", thereby leaving you completely unprotected.

Accidents only happen in uncontrolled systems. Uncontrolled systems are a PITA. I've worked in enough to know this first hand.

Whether or not to use trigger programs, like anything else, is a business decision. Make your decision based on how the design can best benefit your company, not because you can't control your own security. Agh.

True enough. Security is important ... but security doesn't have an impact on the business rules. Business rules need to be enforced regardless of how security is enforced.

If someone running an application has the authority to update a file (regardless of how ... RPG app, java app, UPDDTA, STRSQL, etc) ... but the update violates a business rule, then the update should be prevented (UNLESS you are doing a special update that needs to bypass the business rules ... but that should be done in a controlled situation).

FWIW: The word 'accident' keeps getting mentioned ... keep in mind that if too many accidents occur, then they cease being accidents and start becoming incompetence ... or, possibly, maliciousness.

david