• Subject: System values vs. the registry (Was: What counts as technically slick?)
  • From: Jim Damato <jdamato@xxxxxxxxxxxxxxxxx>
  • Date: Mon, 9 Apr 2001 18:29:09 -0500

(Do I dare contradict Leif Svalgaard more than once?)

"Editing the registry is not much harder than fiddling with system values."

Yeah, right.  Most MCSE's approach the registry with the appropriate fear
and respect, to the extent of performing full backups before making changes.
Someday Microsoft will take the voodoo out of registry configuration, but
don't expect it any time soon.  When you "fiddle" with AS/400 system values
the valid options and their documentation are built in.  Just press F4 for
your choices and press F1 to read in great detail about the impact of your
actions.

"it is next to impossible to disable the feature ... The only way to disable
the feature is to patch OS/400."

You deliberately didn't choose QALWOBJRST for your example.  *ALL and *NONE
are pretty explicit options for enabling and disabling the restore of
objects with security-sensitive attributes.  (I'm still trying to FIND the
QVFYOBJRST value).

My point was that the system values are supported, documented, integrated
entry points into the system.  Microsoft's new "feature" is a hack for which
altering the configuration is neither supported nor documented.  They've
worked out a quick fix to a high-profile problem.  Maybe they'll provide
full integration later.


-----Original Message-----
From: Leif Svalgaard [mailto:leif@leif.org]
Sent: Monday, April 09, 2001 4:49 PM
To: MIDRANGE-L@midrange.com
Subject: Re: What counts as technically slick?


From: Jim Damato <jdamato@dollargeneral.com>
> Much, much different than QALWOBJRST and QVFYOBJRST:
>
> "With Outlook 2002, Microsoft will compel everyone to adopt the new
security
> measure. The company also makes it nearly impossible for individuals and
> very difficult for corporations to disable the feature, which the company
> says is necessitated by the threat the attachments pose."

I don't see much difference. Let's examine the two quotes you provide.
"The company also makes it nearly impossible for individuals and
very difficult for corporations to disable the feature".
Same thing for IBM:
it is next to impossible to disable the feature. E.g., with QVFYOBJRST,
a system-state program without signature still shows up as a program that
violates the system integrity check, even if you get it restored by
setting QVFYOBJRST = "1". So the feature is not disabled. The
only way to disable the feature is to patch OS/400. Not something
the average Joe should contemplate.

>
> "In fact, Microsoft makes turning off the feature downright difficult.
> Office XP users must physically edit the Windows Registry--an internal
> database of Windows information--to turn off the attachment restriction
> function."

Editing the registry is not much harder than fiddling with system values.

I really don't see any differences. Maybe the biggest similarity is that
the "features" are to *patch* rather than *fix* severe security problems
at the architectural level.


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

This thread ...

Follow-Ups:

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

This mailing list archive is Copyright 1997-2019 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].