× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



FWIW...an "accidental" RMVPFTRG would be a heckuva lot harder since you
have to have an exclusive lock in order to remove it....

Thanks,
Tommy Holden



From:
Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>
To:
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
Date:
06/05/2008 11:43 AM
Subject:
Re: Trigger programme without a trigger.



CRPence wrote:
However it takes
only that one person using either a special profile or a special tool
that gives the developer or implementor all-access to /fix something/,
or an accidental equivalent granting of rights to a user due to error(s)

in security implementation, for the expected access method to be
bypassed on the production system; such a bypass need not even be
malicious.

This is a bit of a red herring, because if you can bypass authority then
you can bypass triggers: all it takes is an "accidental" RMVPFTRG. If
your environment is such that people have access to high security
profiles, then there's no way to protect your data. Your accidental
granting of rights is equivalent to accidentally granting QSECOFR
rights; no amount of security can prevent you from a security failure
that egregious.

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.


FWiW I also prefer that the owner of the database to be a peon user,
so that any program adopting the authority of that owning user, for the
purpose of accessing the database, does not also obtain access to
anything beyond what the active user for the job is already authorized.

Agreed. The owner of the database ought have no authority except to the
data. That's what they do, and that's all they do.

Joe



Editorial note:
Now, if you absolutely must,
you can grant read <ed: "access" inferred vs "writes"> writes
so people can do external queries. That's up to you. But there is
simply no reason to have unfettered update writes to your database.
If you've created a perfectly good database access mediator such as
the I/O module mentioned, then by all means lock the database down -
you will have shut the door on a lot of gremlins.


Actually I somehow managed to type "writes" twice instead of "rights".

Joe

As an Amazon Associate we earn from qualifying purchases.

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

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.