Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

ODBC Security

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • ODBC Security

    What do I have to do to prevent updates on AS/400 files from ODBC users using MS Access? I know that the "other" tab in ODBC administration on the PC can be set to read only, but of course the user can easily change this.

  • #2
    ODBC Security

    On Friday, May 28, 1999, 09:16 AM, david garrett wrote: What do I have to do to prevent updates on AS/400 files from ODBC users using MS Access? I know that the "other" tab in ODBC administration on the PC can be set to read only, but of course the user can easily change this. The answer to your question is, you go to the AS/400 and set access rights on the file. Use the GRTOBJAUT command to grand authority to an object and RVKOBJAUT to revoke it. The question is, how will this impact your existing applications? Two months ago, I had to arrange to have an AS/400 setup on the Internet. The AS/400 was at security level 20. We had to change it to security level 30 and rework some of the applications to enhance security. The AS/400 had been in an office with 8 employees as its only users. The users could not get a command prompt, the only way they could use the AS/400 was through applications and menus. Each user id had full write access to everty file. This was ok when all access is from green screen terminals located in the same office as the AS/400. However the world has changed. With ODBC, FTP, query tools, SQL, you need to set access rights on objects. Particularly on programs and files. On our system, no user id has write access to a file. This means users can use odbc to query data but not write to it. If you set your files so your users can only read your exising applications may not run. A green screen program that writes to one of your files may abort because it can not open the file for writing. To make this work, your programs must use adopted authority. What this means, when a program executes, it will run under some other user's authority. You create a DB user that has write access to your data base. You setup your programs so they use the DB user's authority when they run. Green screen programs that can update files will need to be restricted to certain users. So you go to the pgm object and set access rights to the program. All of this is outlined in the IBM manual "Tips and Tools for securing Your AS/400". Chapters 5 and 6 are about the object authority. Chapeter 5 is titled "Tips for Securing PC Access". The manuals "Security - Basic" and "Security - Reference" go into much more detail. JHicks@SUZ.com

    Comment


    • #3
      ODBC Security

      On Friday, May 28, 1999, 09:16 AM, david garrett wrote: What do I have to do to prevent updates on AS/400 files from ODBC users using MS Access? I know that the "other" tab in ODBC administration on the PC can be set to read only, but of course the user can easily change this. In response to your email asking about details on exit point programs. There are exit points in the Os/400 where the AS/400 will call a program that is registered with the exit point. You can see a list of the exit points and register exit programs to an exit point with the WRKREGINF command. Each exit point will pass differerent parameters to the exit program so you must learn the layout of the parameters required for the exit point you want to use. The exit point format shows the name of include or copy files for the parameters. These are found in QSYSINC. Find the include file for the language you are coding in. I suppose you could use an exit point for SQL and examine the sql statement. I think you are under the impression that it is easier to code an exit program than setup security parameters. Most of the exit points have little or no documentation. You have to figure them out. I would not write a user exit program to do something that can be set by a parameter. JHicks@SUZ.com

      Comment

      Working...
      X