Re: Installing running applications as QSECOFR

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