This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Installing w/o admin generates key error
Type: Stage:
Components: Distutils Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: theller Nosy List: prittenh, tarek, techtonik, theller
Priority: normal Keywords:

Created on 2002-08-27 19:49 by prittenh, last changed 2022-04-10 16:05 by admin. This issue is now closed.

Messages (4)
msg12175 - (view) Author: Phil Rittenhouse (prittenh) Date: 2002-08-27 19:49
I encountered the following problem when trying to 
install a package I had generated with distutils 
(Python 2.2 on Win2k, logged in as a user without 
adminstrative priveleges):

When the installer was run, it would go through the 
steps nicely, but towards the end, it generated two 
errors:
        "Could not open key
Software\Microsoft\Windows\CurrentVersion\Unins
tall"
        "Could not create key  dsp-py2.1"

At first I thought the problem might be the result 
of installing Python as Administrator, and the 
package as just a user, so I re-installed Python as a 
user, but I still got the same error.  I ran my test on 
Win2K with both Python 2.1 and 2.2, and I always 
got the same result.

I tracked the code generating the error to install.c in
distutils-1.0.2/misc (see below).  I did some 
digging and it appears that to use 
KEY_ALL_ACCESS, the code must be running
with Administrator privileges.   I checked the CVS 
archives to see if KEY_ALL_ACCESS is
still being used, and it is.

I made the following changes to install.c (from 
Distutils 1.0.2), recompiled, and it  works now.
796c796
<                         KEY_CREATE_SUB_KEY,
---
>                         KEY_ALL_ACCESS,
806c806
<                           KEY_WRITE,
---
>                           KEY_ALL_ACCESS,
1177c1177
<                KEY_WRITE,
---
>                KEY_ALL_ACCESS,
1208c1208
<                KEY_WRITE,
---
>                KEY_ALL_ACCESS,


I chose KEY_CREATE_SUB_KEY for the open, since 
that is the only operation that will be performed
on it.   For the new key itself, I chose KEY_WRITE, 
since that was also the minimal operation.  While I
was at it, I changed the code for deleting the 
registry key and value to also use the minimal 
KEY_WRITE.  The last two changes allowed the 
uninstaller to work properly when run as a normal 
user.
msg12176 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2004-12-22 15:54
Logged In: YES 
user_id=11105

I believe this is long fixed.
msg107213 - (view) Author: anatoly techtonik (techtonik) Date: 2010-06-06 19:37
Seems like it still the issue for 2.4.4

http://scons.tigris.org/issues/show_bug.cgi?id=2533
http://trac.edgewall.org/ticket/9404#comment:2
msg107218 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2010-06-06 19:58
2.4/2.5 are not fixed anymore. Only security patches.
History
Date User Action Args
2022-04-10 16:05:37adminsetgithub: 37094
2010-06-06 19:58:19tareksetmessages: + msg107218
2010-06-06 19:37:26techtoniksetnosy: + tarek, techtonik
messages: + msg107213
2002-08-27 19:49:55prittenhcreate