×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Joe Pluta wrote:
I would argue that you don't need QSECOFR for most operations. If the
product is required to adopt authority of profiles, it would be just as
easy to grant *USE authority to those profiles which it needs to adopt.
There is rarely a need to have QSECOFR rights.
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.
In the case of MKS Implementer, we a very strong security mechanism that
protects any program that has to adopt higher authority from misuse.
Mind you, when Implementer is not actually moving code around, it is
still adopting authority ... but the profile is a single 'product owner'
profile that has very limited capabilities (by default).
In those rare cases where it might be required, what I'd like to see is
something like su in Linux, where you would have to key in the QSECOFR
profile to execute a particular function.
Queue John Earl :)
david
(who works for MKS in addition to running these lists)
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
