Re: Installing running applications as QSECOFR

David Gibbs wrote:

In general you are correct ... but most SCM products have to manage MANY
differing objects, in many different libraries, with many differing
authority models. Having to grant the necessary authorities for all
those different conditions is just not practical.

Ugh. This sounds perilously close to the "it's too hard so just grant QSECOFR" argument. But be that as it may...

Additionally, there are certain functions that just can't be done
without QSECOFR authority ... user profile handle switching, for
example. You an do it if you know the user and password you are
switching to, but in order to do the handle switch WITHOUT requiring the
userid & password, you need QSECOFR authority.

Have you tried password *NOPWDCHK? You only need *USE authority to the profile. (And of course, there's always the old standby of simply submitting a job under that user profile. If you have *USE authority, you can do that no problem.) I still don't buy the idea that you need QSECOFR to manage non-QSECOFR objects.

Now, if you are managing objects owned by QSECOFR, then yes, the black hole opens. But it's rare in my mind that application objects need QSECOFR authority.

Well, as it happens, we use Implementer to manage the development of
Implementer ... and, yes, we have to manage programs that adopt QSECOFR
authority :)

I understand that, but my point is that the requirements for managing security objects should not then require the same procedures apply to non-security objects. Specifically, programs that are owned by QSECOFR should follow a special path.

And of course, we're still discussing an SCM system, which as you state is closer to a system function than an application. However, I still think that just because you sometimes need QSECOFR, that shouldn't require you to need it all the time.

Joe