seven_shen has asked for the wisdom of the Perl Monks concerning the following question:

#!/usr/bin/perl -w use strict; use Win32::TieRegistry; my $PID_KEY_ROOT = "LMachine\\SOFTWARE\\"; my $PID_KEY = "Test"; my $reg = new Win32::TieRegistry $PID_KEY_ROOT, {Delimiter=>"\\"}; print "$reg\n"; $reg->CreateKey($PID_KEY) or die("$^E\n");

The test is to add one Key in registry. The above codes works normally in administrator priviledge, but couldn't run in standard user, for example in WIN7/Vista with UAC enabled:

Use of uninitialized value $reg n concatenation <.> or string at test. +pl line 8. Can't call method "CreateKey" on an undefined value at test.pl line 9.

Seems the module can not work successfully if some keys in registry is out of user priviledge.

Some guys suggest to add Access control like:

#!/usr/bin/perl -w use strict; use Win32::TieRegistry; my $PID_KEY_ROOT = "LMachine\\SOFTWARE\\"; my $PID_KEY = "Test"; my $reg = new Win32::TieRegistry $PID_KEY_ROOT,{Access=>"KEY_READ",Del +imiter=>"\\"}; print "$reg\n"; $reg->CreateKey($PID_KEY) or die("$^E\n");

This works for:

 my $reg = new Win32::TieRegistry $PID_KEY_ROOT,{Access=>"KEY_READ",Delimiter=>"\\"};

but fails for:

$reg->CreateKey($PID_KEY)

The output is : Access is denied

Any solutions(substitutions)?

Replies are listed 'Best First'.
Re: Deficiency of Win32::TieRegistry in user priviledge
by Anonymous Monk on Jun 17, 2011 at 07:48 UTC
    Any solutions(substitutions)?

    You need to run perl.exe with elebated privilige/permission from UAC, no way around that. See Perl And Seven UAC click

Re: Deficiency of Win32::TieRegistry in user priviledge
by Anonymous Monk on Jun 17, 2011 at 08:11 UTC
    Maybe you want CUser aka HKCU aka HKEY_CURRENT_USER?

    I thought Vista/UAC virtualized access to HKEY_LOCAL_MACHINE, so a regular user can write and it really goes to HKEY_CURRENT_USER... but I don't have vista

Re: Deficiency of Win32::TieRegistry in user priviledge
by locked_user sundialsvc4 (Abbot) on Jun 17, 2011 at 13:08 UTC

    It’s just a basic fact of life that the Registry, like many other system resources, is subject to access controls, and that your code might be run by someone who has the appropriate access privileges or by someone who does not.   It must respond “gracefully and appropriately” either way ... even if that means terminating the program with a message to the effect that “sorry, you must be a god to run this.”

    I would probably define an application-specific wrapper class to encapsulate all of the registry access that I needed the program to do.   If Win32::TieRegistry returns an error-message or throws an exception, this wrapper would (probably) detect the problem and throw an exception, e.g. with Exception::Class.

    And, yes, if I knew that the program has to be run by someone with godly powers, I would include a privilege-check at program startup, and terminate the program if this user cannot do what must be done.   I have a strong aversion to programs that ... and I’m not speaking of you, specifically ... “have very obviously only been tested by developers who are running as administrators of their own systems.”