Re: Trigger programme without a trigger.

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

David Gibbs wrote:
> Joe Pluta 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.


> 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?

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


> > Basing your architecture on the fact that you can't enforce your own 
> > security rules seems to me to be a bad way to do things.
> >     
>
> However, basing your architecture on the assumption that a single RPG 
> application is going to be the ONLY possible way to update a file when 
> this may not necessarily remain the case, is probably a bad way to do 
> things also.
>   
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.

I'm not saying it's the only way, mind you.  I'm just saying that it can 
be done, and it can in fact be done quite easily.


> 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.

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.

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.

If you can'[t count on your security in production, you need someone 
else in charge of security.

Joe