Re: Installing running applications as QSECOFR

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

John Earl wrote:
> > 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.
> >     
>
> User profile switching requires *USE to the object.  Given the
> difficulty of creating your own "FRED" profile and making sure it always
> has *USE authority to every profile it might ever want to switch to
> (including profiles not yet created), giving "FRED" *ALLOBJ seems like a
> reasonable compromise.  But it is likely also be unnecessary to provide
> "FRED" with the other seven Special Authorities.
>   
I don't even buy the *ALLOBJ, John.  It seems to me that any automation 
process - and in the end, that is what an SCM system is: an object 
distribution automation - ought to follow the exact same security 
policies as the manual procedures it replaces.  In the case of object 
creation and distribution, the programmer does the initial object 
creation.  My guess is they don't ever need to sign on as QSECOFR or 
indeed as anything but their own profile to do their job.  So that part 
of the process ought to run under their profile.  And I don't think it's 
too hard to identify the profile to the SCM; that would be part of your 
standard procedure of setting up a programmer, wouldn't it?  I mean, 
really, how much work is it to grant authority to a user profile?

Object promotion is different, but once again in my opinion it ought to 
exactly mirror the manual process.  Now, if in your shop you have to 
sign on as QSECOFR every time you put a program into production, then 
probably you have an argument that you need to assign QSECOFR to that 
task in your SCM.  However, I think we would probably all agree that 
requiring QSECOFR to install into production probably isn't the best 
answer.  Instead, there should probably be a "PROMOTE" user profile that 
has enough authority to do these things, and that is the profile that 
the promotion task should run under.

I don't know, maybe I'm missing the boat.  It sure seems to me, though, 
that given the ease with which we can swap profiles today that it ought 
to be a piece of cake to use the right profile for a task, rather than 
use carte blanche authority.

Joe