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



If they have access to the command UPDDTA or can update a file from a PC 
then I would argue that they can probably call the I/O module.  And I 
assumed that the I/O module would have done some sort of adopting 
authority.  Now, if you needed some different authority to have access to 
the I/O module, like program B adopts user SAM which gives it access to 
the I/O module, which then adopts user MARY to have access to the data, 
that might work.

As far as a programmatic interface, that's security by obscurity.  You 
should have seen the bug eyed IBMer's a few years back in Rochester which 
called the iSeries Navigator API's from the command line, passing the 
necessary hex codes, just lightning fast.

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 




"Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
11/17/2003 03:43 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"'RPG programming on the AS400 / iSeries'" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: ALL I/O in single module was(ARGH!!! (was file open with LR))






> From: rob@xxxxxxxxx
> 
> And what would restrict the public from being able to call the I/O
module?
>  Security-by-obscurity?

OS/400 object authority.  And since it's only a programmatic interface
not designed to be called from a command line, even if a user gets
access to a command line they can't just invoke the I/O module.

Now, an unscrupulous programmer could indeed write an interface to the
I/O module and then grant authority to a production user who could then
use it to update data.  If that's your concern, then you need one more
level of security, wherein the trigger program checks for a valid caller
to the I/O module.  You also need probably need a better screening
process for your developers <grin>.

Of course, if you have unscrupulous programmers with access to
production data, then you have much larger security problems.  This is,
however, a good reason to not allow programmers authority to production
data <smile>.

Anyway, this is pretty basic stuff.  I think if you sat down and worked
through the issues yourself you'd see how a combination of adopted
authority and proper security can completely lock down your data under
most normal circumstances.

Joe

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



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.