SQL/400: STRSQL command

550 pts.
AS/400 security
AS/400 user profiles
Start Structured Query Language
Hi friends, I have on my system many users with the userclass *SECOFR. How can I determine only one user to use the command STRSQL?

Answer Wiki

Thanks. We'll let you know when a new response is added.

I’ll give it a shot — so someone can prove how stupid I really am.
The users with *SECOFR probably have All Object authority.

Normally I would say: if you change the Authority on an object (STRSQL cmd) to exclude specific ID that’s it would exclude use of that object by that user.

But with all object authority and SECOFR I doubt that will work.


Discuss This Question: 5  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Gilly400
    Hi, If you can, you should change those users to non-*SECOFR profiles. *SECOFR is only meant to be used by people for security management purposes. If you're stuck with this situation, you may be able to restrict the people using STRSQL by creating your own STRSQL command higher in the (system) library list, which just gives an error message saying STRSQL is not allowed. You can then still use STRSQL by specifying the library name for the real command :- QSYS/STRSQL There's not much point in object level security if everyone has *ALLOBJ and *SECOFR authority. Regards, Martin Gilbert.
    23,730 pointsBadges:
  • Yorkshireman
    MArtin said it - restrict *secofr to few or None. (the password stays in a sealed envelope for use when needed, and the password changed after use) It's not just security - *secofr has the ability to alter configurations, inadvertently do damage to the database and applications acidently and so on. I've been on sites like yours, and they're usualy because someone once had difficulty in doing something, and discovered that by being *secofr it 'worked'. As *secofr, objects you create are under your level of profile, so the next person also needs *secofr to be able to work. You'll first need to find out what objects are secured by *secofr profile wrkusrprf, and display objects owned. use 'display authority' on some likely ones and check that *public (or another group you may have) has suitable authorities. alter and reassign authorities using GRTOBJAUT - you could start by making everything owned by, say *USER and granting all authorities to *public, then devore time to tightening the rules for things like configuration objects ( *OPERATOR) or payroll (*MANAGER) or you could find out what should be what and set it up as needed. Convert your users one at a time and be prepared to correct any surprises thrown up. Auditors like this kind of stuff. If you need resource to do the job you say 'if the auditors find out our information is so insecure they may qualify the acounts'
    6,085 pointsBadges:
  • Cwc
    "(the password stays in a sealed envelope for use when needed, and the password changed after use) " ...and it's kept in a mayonaisse jar at Funk and Wagnall's, and only The Great Karnac can discern its contents without opening! (Just couldn't resist). :)
    4,290 pointsBadges:
  • Yorkshireman
    Hey - I worked there, I didn't make up the rules. There are alternative strategies that are more effective. It used to be the case, but I don't think so now, that the real live *Secofr profile was needed for a couple of things. Nowadays, with other profiles capable of having *secofr authority, that 'responsible' kiddies (like me) can have a second *secofr profile to sign on and do damage. Your fingerprints are left behind so what you do is traceable to an individual. 99 percent of the time I'm happy to use a profile with NO authority to damage objects in the production system. - which should be the normal state for all *users. a *Pgmr authority provides plenty of scope for development, and a bit more access to view, not amend, production data, use a command line and so on. Treat * secofr with respect! - and anyway, it was a marmalade jar when I worked there. :- )
    6,085 pointsBadges:
  • TomLiotta
    *SECOFR user class is related to special authorities in that the related default set of special authorities is assigned when a profile is created as *SECOFR class. However, those special authorities may be changed (reduced) while still retaining the class. After the profile has been created, the long-term purpose of the class is to enable various options on different menus. A *SECOFR will see different menu options than a *PGMR. If required special authorities have been removed from the profile, the options won't work. A couple other attributes also apply. The assumption, though, for a *SECOFR class user should be that all special authorities are available. And if *ALLOBJ is actually available, then it should be assumed that any other special authority can be obtained. As such, there is no way to restrict an *ALLOBJ user from anything. Whatever you do can be undone or circumvented. (If the user doesn't know how, a question posted to a site such as this one can often get an answer.) Tom
    125,585 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: