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



> From: oliver.wenzel@xxxxxxxxxxxxxxxxxxxxxxx
>
> So, without exit-point programming or buying some security product, I
> cannot fix these loopholes? Thanks a lot, IBM..

I'm still not sure I see the loophole, Oliver.  What are you worried about?

1. If you secure access with *PUBLIC *EXCLUDE, nobody can access your data,
INCLUDING through an external query.  This is the "standard" or "command
line" security model of days gone by.  They can only look at data if there's
a green screen program that lets them.  The problem is that if a ser wants
access, you have to write a program.  No ad hoc user queries.

2. If you secure access with *PUBLIC *READ (or give specific users READ
access to specific files), then your users can read the data, but not update
it, using standard query tools.  The problem here is that you do not have
row and column level security for specific users, which means any user can
read any field in the file.

3. If you want specific row/colunm access, you can set up logical files for
each user or group that specifically limits them to access of data, and only
allow *READ access to these files.  This will limit the data that can be
read by a given user.

Given those scenarios, what are the loopholes you are worried about?  The
only thing I see is that you may have to do some work, especially if you
need row/column security.  Note that you CAN also get this level of security
through exit programs, triggers or third party security products (which
generally make use of all of the above).  But you don't HAVE to.  OS/400
security is quite capable of handling anything you need, but it requires
planning and execution.

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.