Modified registry keys, can't restore permissions

Discussion in 'HP' started by Fred Ma, Jul 3, 2004.

  1. Fred Ma

    Fred Ma Guest

    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" <>
    I will manually prevent the thread from fragmenting.
     
    Fred Ma, Jul 3, 2004
    #1
    1. Advertisements

  2. Fred Ma

    Ben Myers Guest

    Yes, an exported copy of the registry would have helped. It contains everything
    the real registry contains... Ben Myers
     
    Ben Myers, Jul 3, 2004
    #2
    1. Advertisements

  3. Fred Ma

    Fred Ma Guest


    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, Jul 3, 2004
    #3
  4. Fred Ma

    Aidan Grey Guest

    (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 Grey, Jul 3, 2004
    #4
  5. Fred Ma

    Ben Myers Guest

    Fred,

    There's a very fundamental issue here, and Micro$oft and Hp are BOTH culpable.

    With Windows 2000, only an administrator can install software. There is no
    clean and easy way to work around this, unless the software install takes this
    into account somhow (usually by faking admin priveleges during the install).
    Thank Microsoft for this one.

    I first ran into this problem with either ROXIO or Nero (I forget which) CD
    burning software which never installed right on a Win 2000 system, and you could
    not burn a CD unless you had admin privileges. The company finally issued a
    patch to work around the problem.

    The above is fine for the corporate IT weenies for who Win 2000 was intended,
    but for those of us who have to do real work with computers, it simply sucks.

    Sounds like HP fell into the same trap... Ben Myers
     
    Ben Myers, Jul 4, 2004
    #5
  6. Fred Ma

    Fred Ma Guest

    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, Jul 4, 2004
    #6
  7. Fred Ma

    Fred Ma Guest


    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.

    Fred
     
    Fred Ma, Jul 4, 2004
    #7
  8. Fred Ma

    Fred Ma Guest


    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, Jul 4, 2004
    #8
  9. Fred Ma

    Fred Ma Guest

    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, Jul 4, 2004
    #9
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.