Re: Installing running applications as QSECOFR

Joe Pluta wrote:

I have to defer to your knowledge, but as far as I know, you should never need more authority to manage an object than the owner of that object. Theoretically you should only need *USE authority to those profiles which own the application objects.

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.

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.

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 :)

In fact, I would go so far as to say that a CMS system should have a mechanism by which certain objects could be designated as "secure" objects. Management of these objects would require a special CMS profile with special authority outside the realm of normal application development. The point being that Disgruntled Developer shouldn't be able to modify, say, the system startup program.

Well, Implementer (and I would assume the other major players in the
area) have pretty strong authority checking and control mechanism in
place to prevent the wrong people from doing things they aren't supposed
to do. So if developer A isn't supposed to push changes from
development to QA, they won't be allowed to.

david