Re: Installing running applications as QSECOFR

David Gibbs wrote:

Sure, but the same programs that move the QSECOFR owned objects along the special path are used to move normal objects along a normal path. Which authorities are used?

My point is that perhaps the profiles used during normal operation of the tool shouldn't be the same as the profile used for moving QSECOFR owned objects. And then, if the tool didn't adopt QSECOFR specifically, any attempt to move a security object from a non-security profile would fail, and in fact would be impossible.

I don't know, we seem to be at an impasse. I've done enough security work from my standpoint to think that, given a little time, you could avoid the necessity for QSECOFR access EXCEPT in the rare occasion when you manage a QSECOFR-owned object. That sort of work should require a regular application programmer to sign off and then sign back in with a special profile, one that has been specifically created to handle QSECOFR-owned objects.

Done this way, you would not need QSECOFR on installation, nor would you ever need to specifically switch to QSECOFR.

But we've gone far, far afield. It's unlikely MKS is going to change its philosophy. But if I were an auditor, I would still be waiting for a good reason to grant QSECOFR authority to an SCM product. One profile that uses the product, specifically to create QSECOFR objects, sure. But not the product in general.

Joe