Re: Installing running applications as QSECOFR

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

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