Modified registry keys, can't restore permissions

[Guest]

Archived from groups: comp.sys.hp.hardware (More info?)

I was having trouble uninstalling some drivers for my HP
printer/scanner (HP support, please note that this is
case#7312033464). I got a lot of help from tech support. There is
one difficulty I am left with, though. One of the steps needed for a
thorough uninstall was to open up permissions for the following
registry keys:

HKEY_CLASSES_ROOT (top level of the tree)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum
HKEY_LOCAL_MACHINE\System\ControlSet001\Enum

The change was to give the Everyone account "Full Control". I thought
it was a temporary change. The problem is that it cannot be reverted
back to its previous permissions. If I try to take away Full Control
from the Everyone account, the nonadministrator account is not able to
launch windows explorer. I had to use the task manager to issue a
runas and launch the windows explorer as administrator.

I suspect that what is happening is that taking away Full Control in
those subtrees causes a removal of that permission for all
nonadministrators, throughout the entire subtrees. This probably not
reflect the state of the registry prior to my granting those
permissions. HP has told me that this is a standard way to get around
the problem of nonthorough uninstalls. I was advised to talk to Dell
Technical support to figure out how to fix it.

Dell was willing to help, but they said the only way to deal with it
was to reinstall windows. This is supposedly a major compromise in
security, and allows any nonadministrator to install applications on
the system. I just wondered if gurus out there can suggest a last
ditch attempt at restoring the permissions. I just reinstalled
Windows 2000 Pro for the 2nd time in a month. (The first time was on
a bad HDD). The major time sink is not the reinstallation of windows,
or SP4. It is the installation and customization of apps and
environments that I use.

Thanks for any suggestions.

Fred

P.S. Would exporting a copy of the registry have helped? I mean,
does the export include permissions information?

P.P.S. Please note that this has been sent to
- comp.sys.hp.hardware
- microsoft.public.win2000.general
- "HP OfficeJet E-mail Support" <officejet_support_en@mail.support.hp.com>
I will manually prevent the thread from fragmenting.
--
Fred Ma
Dept. of Electronics, Carleton University
Ottawa, Ontario, Canada

 

[Guest]

Archived from groups: comp.sys.hp.hardware (More info?)

Yes, an exported copy of the registry would have helped. It contains everything
the real registry contains... Ben Myers

On 3 Jul 2004 06:10:41 GMT, Fred Ma <fma@doe.carleton.ca> wrote:

>I was having trouble uninstalling some drivers for my HP
>printer/scanner (HP support, please note that this is
>case#7312033464). I got a lot of help from tech support. There is
>one difficulty I am left with, though. One of the steps needed for a
>thorough uninstall was to open up permissions for the following
>registry keys:
>
> HKEY_CLASSES_ROOT (top level of the tree)
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum
> HKEY_LOCAL_MACHINE\System\ControlSet001\Enum
>
>The change was to give the Everyone account "Full Control". I thought
>it was a temporary change. The problem is that it cannot be reverted
>back to its previous permissions. If I try to take away Full Control
>from the Everyone account, the nonadministrator account is not able to
>launch windows explorer. I had to use the task manager to issue a
>runas and launch the windows explorer as administrator.
>
>I suspect that what is happening is that taking away Full Control in
>those subtrees causes a removal of that permission for all
>nonadministrators, throughout the entire subtrees. This probably not
>reflect the state of the registry prior to my granting those
>permissions. HP has told me that this is a standard way to get around
>the problem of nonthorough uninstalls. I was advised to talk to Dell
>Technical support to figure out how to fix it.
>
>Dell was willing to help, but they said the only way to deal with it
>was to reinstall windows. This is supposedly a major compromise in
>security, and allows any nonadministrator to install applications on
>the system. I just wondered if gurus out there can suggest a last
>ditch attempt at restoring the permissions. I just reinstalled
>Windows 2000 Pro for the 2nd time in a month. (The first time was on
>a bad HDD). The major time sink is not the reinstallation of windows,
>or SP4. It is the installation and customization of apps and
>environments that I use.
>
>Thanks for any suggestions.
>
>Fred
>
>P.S. Would exporting a copy of the registry have helped? I mean,
>does the export include permissions information?
>
>P.P.S. Please note that this has been sent to
> - comp.sys.hp.hardware
> - microsoft.public.win2000.general
> - "HP OfficeJet E-mail Support" <officejet_support_en@mail.support.hp.com>
>I will manually prevent the thread from fragmenting.
>--
>Fred Ma
>Dept. of Electronics, Carleton University
>Ottawa, Ontario, Canada

 

[Guest]

Archived from groups: comp.sys.hp.hardware (More info?)

Ben Myers wrote:
>
> Yes, an exported copy of the registry would have helped. It
> contains everything the real registry contains... Ben Myers


My apologies, but I goofed and sent a partial response. Here
is the complete response.

Thanks, Ben. I hope HP modifies its instructions to include a step to
export the registry in its procedure. There is simply no excuse for
not taking this precaution, especially if the procedural information
does not inform the user about the irreversible compromise in
security.

The best solution, however, is to modify the software so that such
contortions are not required. Based on discussions with tech support,
my understanding is that the software was targeted toward older
Windows OS's, ones that do not distinguish between different users and
restrict access based on that. The registry hack seems like it
cripples the security in NT-based OS's and bring it down to the lowest
denominator. In this case, there isn't much point in using a
nonadministrator account for regular work in order to minimize
potential damage due to malware.

Prior to doing extensive investigation into the problem, Dell was
suggesting that I could do a Windows repair. This would bring the
registry back to the state of Win2K Pro, SP1. I would then reapply
SP4 (which would take an eon to download again, since my connection is
rather slow). I was worried that this would create problems with
self-consistency in the software that was installed. They were
installed after SP4 was applied, so I'm not sure what kind of registry
changes they expect to have in place. Repairing Windows and
reapplying SP4 might wipe out some of these changes.(I'm guessing, not
knowing much about how the registry works). As I mentioned,
installing and customizing the applications is the major time sink,
not the reinstall of Win2K with SP4 (though that is no trivial matter
either).

This prompted the phone support technician to inquire further. The
final response was that the permission changes to the aforementioned
keys (below) were indeed so fundamental that such a repair would be
unlikely to work. I baffles me this change can be advised in such a
cavalier way without first informing the users of the ramifications.
In fact, I was vocally expressing these security concerns repeatedly
to HP support prior to performing the steps. It was just a suspicion
on my part. I was assured that it was no big deal (repeatedly).
While I don't recall the exact wording, I was condescendingly and
impatiently given the distinct impression that there was no security
compromise.

If HP cannot devote the resources to change the software, then it
should not list Windows 2000 as a supported operating system for this
PSC 750 printer/scanner/copier. Not if the security has to be
crippled to properly uninstall (many attempted uninstalls were needed
to finally do a "successful" install -- one with limited capabilities
due to supposed incompatibilities with NTFS). In fact, it has taken
so many days of solid banging at this problem that I think it a
misleading omission to blanketly say that Windows 2000 is supported.

Fred
--
Fred Ma
Dept. of Electronics, Carleton University
Ottawa, Ontario, Canada


> On 3 Jul 2004 06:10:41 GMT, Fred Ma <fma@doe.carleton.ca> wrote:
>
> >I was having trouble uninstalling some drivers for my HP
> >printer/scanner (HP support, please note that this is
> >case#7312033464). I got a lot of help from tech support. There is
> >one difficulty I am left with, though. One of the steps needed for a
> >thorough uninstall was to open up permissions for the following
> >registry keys:
> >
> > HKEY_CLASSES_ROOT (top level of the tree)
> > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum
> > HKEY_LOCAL_MACHINE\System\ControlSet001\Enum
> >
> >The change was to give the Everyone account "Full Control". I thought
> >it was a temporary change. The problem is that it cannot be reverted
> >back to its previous permissions. If I try to take away Full Control
> >from the Everyone account, the nonadministrator account is not able to
> >launch windows explorer. I had to use the task manager to issue a
> >runas and launch the windows explorer as administrator.
> >
> >I suspect that what is happening is that taking away Full Control in
> >those subtrees causes a removal of that permission for all
> >nonadministrators, throughout the entire subtrees. This probably not
> >reflect the state of the registry prior to my granting those
> >permissions. HP has told me that this is a standard way to get around
> >the problem of nonthorough uninstalls. I was advised to talk to Dell
> >Technical support to figure out how to fix it.
> >
> >Dell was willing to help, but they said the only way to deal with it
> >was to reinstall windows. This is supposedly a major compromise in
> >security, and allows any nonadministrator to install applications on
> >the system. I just wondered if gurus out there can suggest a last
> >ditch attempt at restoring the permissions. I just reinstalled
> >Windows 2000 Pro for the 2nd time in a month. (The first time was on
> >a bad HDD). The major time sink is not the reinstallation of windows,
> >or SP4. It is the installation and customization of apps and
> >environments that I use.
> >
> >Thanks for any suggestions.
> >
> >Fred
> >
> >P.S. Would exporting a copy of the registry have helped? I mean,
> >does the export include permissions information?
> >
> >P.P.S. Please note that this has been sent to
> > - comp.sys.hp.hardware
> > - microsoft.public.win2000.general
> > - "HP OfficeJet E-mail Support" <officejet_support_en@mail.support.hp.com>
> >I will manually prevent the thread from fragmenting.
> >--
> >Fred Ma
> >Dept. of Electronics, Carleton University
> >Ottawa, Ontario, Canada

 

[Guest]

Archived from groups: comp.sys.hp.hardware (More info?)

(Snip)

You may be able to change permissions more easily using the
REGEDT32.EXE program, rather than REGEDIT.EXE.

I don't know if this will be enough to allow you to reset permissions
the way you want them.

Aidan Grey

 

[Guest]

Archived from groups: comp.sys.hp.hardware (More info?)

Aidan Grey wrote:
>
> (Snip)
>
> You may be able to change permissions more easily using the
> REGEDT32.EXE program, rather than REGEDIT.EXE.
>
> I don't know if this will be enough to allow you to reset permissions
> the way you want them.
>
> Aidan Grey

Aidan, I am using regedt32. I described my suspicion of why it doesn't
work in my original post. Would you have any comment on the validity
of that suspicion? Thanks.

Fred
--
Fred Ma
Dept. of Electronics, Carleton University
Ottawa, Ontario, Canada

 

[Guest]

Archived from groups: comp.sys.hp.hardware (More info?)

Fred Ma wrote:
>
> MS may be responsible for a less than perfect OS, but I believe that the
> current situation is not due to MS. For one thing I *do* use the admin
> account to install software. I do not want the nonadministrator account
> to have that capability. The whole reason for advising that people use
> nonadmin accounts for regular work is for safety. Limited damage in case
> we do something goofy or get infected by malware. Since I was using an
> admin accountn (and was in fact advised to create a 2nd admin acount for
> this purpose, in case permissions were the problem), it is
> puzzling that any registry changes were needed at all. Here is an excerpt
> of some communication, which underlies the reason why I do not blame MS.
>
> Hmm. Actually, I better paraphrase the main idea, since I made some strong
> (though well justified) accusational statements. The main problem is that
> HP is advising certain steps like the registry permission changes without
> including a registry export step. I thought it was missing because the
> permissions change was reversible. I voiced concerns about the security
> risk and reversibility several times. I was condescendingly and impatiently
> told that it was a small matter, and no big deal. All it did was
> allow others to access those keys. I had no idea about the ramifications
> at the time, and it seems that my concerns were simply ignored. I even
> described how I deliberately use a nonadministrator account for its safety.
> Well, if tech expert there knows this and thinks the registry change is OK,
> HP would never compromise their reputation by falsely reassuring me about
> its acceptability, would they??? HP is a very reputable company, and it
> seems like their tech support is pretty knowledgeable. Well, I guess I'm
> wiser.
>
> Another issue is why the driver/installer is built in such a way to need
> such permission changes at all. In fact, even with this change, the
> software ran into some serious problems, which were attributed to my use
> of NTFS. Apparently, NTFS didn't even exist when this product was released.
> That is understandable, but it does not excuse the blanket statement that the
> product works under Windows 2000. Not only does it require the FAT32 of
> earlier windows systems, it must cripple Win2K's security distinction between
> different users to even partially work. And this is with quite a large number
> of days of trying to make it work.
>
> We may blame MS for many anguishes over their OS, but the above two paragraphs
> are why I do not blame MS in this case.


I should add that the partial funcionality of Director was identical to the
result of installation prior to the registry change. Basically, I believe
that I compromised the security of the system for nothing. If the problem
is in fact due to incompatibilities with NTFS, I find in incomprehensible
that HP was not aware of this. There are two possibilities. One is that
such an incompatibility was given as the explanation simply to close the
case. The other is that this incompatibility is not being disclosed. The
2nd possibility seems like an unfair assessment. Normally, I would think
this, but looking at how I was advised to change the registry permission in
such a cavalier manner (with valid suspicions and protests brushed aside),
I think it wise to be more suspicious and less naive. I find it unethical
for tech support to push customers along a path simply to get the product
working (even though it made no difference), regardless of the damage to the
customer's sytem. This last generalization does not just apply to HP. I
have on more than one occassion said "Wait a minute, isn't that just the
precursor to a Windows repair?". The reality is, the customer has to live
with the damage later, while the tech support can close the case and claim
to have dealt with that single isolated issue (which might very well be
true, damage notwithstanding).

Fred
--
Fred Ma
Dept. of Electronics, Carleton University
Ottawa, Ontario, Canada

 

[Guest]

Archived from groups: comp.sys.hp.hardware (More info?)

George wrote:
>
> You know what I do when "Customer Support" tells me to do something I know will damage my system. I say "OK it's done and it still doesn't work." Then if they don't have any more bright ideas I give up.

The problem was my own ignorance of the registry.
At the time of the modification, it seemed simple. They would never put the instructions
into the procedure if it damages the system, and the reason for the lack of precaution must
be that keys were not being removed or having their values changed. Hence the security
change must be simple to reverse. At no time was it clear that changes affect entire
subtrees rather than just the node in the tree being viewed. For example, the Full Control
box was clearly unchecked; if the settings of that box is associated with all the different
nodes in the subtree, how could it be so clearly unchecked when the setting can vary from
node to node? Ergo, the permissions panel must be for the selected node only, so it would
be easy to change the setting back. Another possibility was that the checkbox does in fact
represent the state of the Full Control parameter for all nodes in the subtree, and the only
reason that it could be so clearly unchecked was that all the nodes had that permission
turned off. In this case, too, it would be easy to set the checkbox back to its original
unchecked state, and have that propagate throughout the subtree. Never would I have
suspected that an unchecked represents a subtree with some nodes deactivating Full Control
and other nodes activating it. Some programs, such as FrameMaker, will gray out fields/
switches for which the parameter is not the same throughout all the items in the selected set.
In other places, it will have "As Is" in the appropriate fields. The point is that there are
clear ways to indicate this, but information is conveyed in an easily misinterpreted manner
with Regedt32. So perhaps Ben is right in putting some of the blame with microsoft. Seeing
the grayed out permission controls would have clued me into the nonhomogeneous setting of
Full Control throughout the subtree; the difficulty in reversing a setting would be obvious.

fred
--
Fred Ma
Dept. of Electronics, Carleton University
Ottawa, Ontario, Canada