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



Rob:

My initial thought was on the idea that QSECOFR could do things that no other 
profile could do. I don't know if that's true (outside of the normal stuff like 
signing on to the console, DST, etc., that we're mostly all aware of).

I'll talk here in purely hypothetical terms in order to illustrate.

Say QSECOFR was the _only_ profile that could permanently replace the SEPT with 
a tampered version without any audit trail and that was the _only_ special 
power it had. If that were true, would you be more or less likely to trust a 
vendor who would only let you run the install under QSECOFR and refused to 
divulge the install code? An install shouldn't need to be secret.

Under such circumstances, there should be no reason an install couldn't run 
under any other *SECOFR profile unless there was going to be an unaudited SEPT 
change.

>From that thought, I wondered if any IBMer (or authoritative non-IBMer) could 
>give a reason why QSECOFR might be required by anyone but IBM for an install 
>of anything.

Personally, I first got into the habit of using a different *SECOFR profile 
years ago for a different reason. At one point, we were signed on under some 
IBM Q* profile, it wasn't QSECOFR but that's irrelevant, and during the 
process, a problem caused damage to the signed on profile. It had to be 
recreated.

Whenever possible after that, I always created and used secondary profiles and 
left the Q* profiles alone. I never wanted to find out what recreating QSECOFR 
might entail. It just seemed less risky never to use it except when absolutely 
necessary.

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

>   6. RE: Can We retire the QSECOFR userid? (rob@xxxxxxxxx)
>
>Maybe some of those vendors decided to put the development dollars into
>improving their product instead of getting around requiring QSECOFR.
>Granted it ain't that much to work around.  But, sometimes it amazes me
>how a "simple change" sometimes adds up.

-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com


__________________________________________________________________
New! Unlimited Netscape Internet Service.
Only $9.95 a month -- Sign up today at http://isp.netscape.com/register
Act now to get a personalized email address!

Netscape. Just the Net You Need.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.