RE: Installing running applications as QSECOFR -- MIDRANGE-L

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Tuesday, April 01, 2008 4:55 PM
To: Midrange Systems Technical Discussion
Subject: Re: Installing running applications as QSECOFR

David Gibbs wrote:

In the case of SCM products, the authority REALLY is needed ... because
they have to be able to _manage_ the authorities of the code they are
moving around. It's hard to manage the (often vastly differing)
authorities of other code unless you have adequate authority. In these
cases, QSECOFR authority is a necessity.

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. 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.

David,

I'm not (quite ;) ready to defer to your knowledge on this. Can you provide a concrete example?

Like Joe, my experience has been that a CMS needs *ALL authority to any object it manages, but that
authority is enough to grant access to the object to any other profile on the system.

In a quick test of an object my profile has authority to, I had no trouble giving QSECOFR *ALL
authority to the object; even though I don't have authority to the QSECOFR user profile.

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.

My guess is that most CMS systems would have something like that
available.

Joe

Don't know about Implementer, but with Aldon, we have to segregate secure objects into a different
application/release definition.

Authority to an object is at the application/release level not the object level.

Charles Wilt
Software Engineer
CINTAS Corporation - IT 92B
513.701.1307

wiltc@xxxxxxxxxx

This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.