Re: [Python-Dev] RELEASED Python 2.4, alpha 2

Discussion in 'Python' started by =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Aug 5, 2004.

  1. Anthony Baxter wrote:
    > Python 2.4a2 is an alpha release. We'd greatly appreciate it if you
    > could download it, kick the tires and let us know of any problems you
    > find, but it is not suitable for production usage.


    The Windows installer should support upgrading from a previous Python
    2.4 installation. If you have previously installed 2.4a1, you may try
    this out; please report any problems you find.

    Regards,
    Martin
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Aug 5, 2004
    #1
    1. Advertising

  2. "Martin v. Löwis" <> schrieb im Newsbeitrag
    news:...
    | Anthony Baxter wrote:
    | > Python 2.4a2 is an alpha release. We'd greatly appreciate it if you
    | > could download it, kick the tires and let us know of any problems you
    | > find, but it is not suitable for production usage.
    |
    | The Windows installer should support upgrading from a previous Python
    | 2.4 installation. If you have previously installed 2.4a1, you may try
    | this out; please report any problems you find.
    |
    | Regards,
    | Martin

    What surprised me a little is that on Win XP I could install 2.4a2 as a user
    with restricted rights over a previously administrator-installed
    for-all-users 2.4a1 standard-paths-used installation without
    warnings/problems - well, except for the obvious errors writing to the
    registry (and yes, I tried it intentionally ;). I am not entirely on board
    with the MSI's capabilities, but is there a way to tell the user (before the
    registry errors happen), that he/she may have insufficient rights to
    install?

    --
    Vincent Wehren
     
    Vincent Wehren, Aug 6, 2004
    #2
    1. Advertising

  3. Vincent Wehren wrote:
    > What surprised me a little is that on Win XP I could install 2.4a2 as a user
    > with restricted rights over a previously administrator-installed
    > for-all-users 2.4a1 standard-paths-used installation without
    > warnings/problems - well, except for the obvious errors writing to the
    > registry (and yes, I tried it intentionally ;). I am not entirely on board
    > with the MSI's capabilities, but is there a way to tell the user (before the
    > registry errors happen), that he/she may have insufficient rights to
    > install?


    I'm not quite sure I understand what you were doing, and in what way
    this has surprised you. It seems
    - you made a per-machine installation as the administrator
    - you then upgraded as a restricted user (not being asked whether this
    is going to be per-user or per-machine)

    What *should* have happened is this:
    - MSI finds that the new installation is per user, and the old
    installation is per-machine, so no upgrade is possible
    - the UI then tells you that the target directory already exists,
    and wants confirmation
    - if you proceed, it overwrites the existing files, creating a
    per-user installation (i.e. shortcuts in your profile, registry
    keys in HKEY_CURRENT_USER)

    Are you saying that somebody else has happened instead?
    If not, in what way did that surprise you?

    Regards,
    Martin
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Aug 6, 2004
    #3
  4. "Martin v. Löwis" <> schrieb im Newsbeitrag
    news:4113429a$0$26993$...
    > Vincent Wehren wrote:
    > > What surprised me a little is that on Win XP I could install 2.4a2 as a

    user
    > > with restricted rights over a previously administrator-installed
    > > for-all-users 2.4a1 standard-paths-used installation without
    > > warnings/problems - well, except for the obvious errors writing to the
    > > registry (and yes, I tried it intentionally ;). I am not entirely on

    board
    > > with the MSI's capabilities, but is there a way to tell the user (before

    the
    > > registry errors happen), that he/she may have insufficient rights to
    > > install?

    >
    > I'm not quite sure I understand what you were doing, and in what way
    > this has surprised you. It seems
    > - you made a per-machine installation as the administrator


    True.

    > - you then upgraded as a restricted user (not being asked whether this
    > is going to be per-user or per-machine)


    True

    >
    > What *should* have happened is this:
    > - MSI finds that the new installation is per user, and the old
    > installation is per-machine, so no upgrade is possible


    Can't say, but I take your word for it ;)

    > - the UI then tells you that the target directory already exists,
    > and wants confirmation


    Yes.

    > - if you proceed, it overwrites the existing files, creating a
    > per-user installation (i.e. shortcuts in your profile, registry
    > keys in HKEY_CURRENT_USER)
    >
    > Are you saying that somebody else has happened instead?


    Well, writing a bunch of the registry keys fails. This user has no rights to
    write them and is greated with several error messages as in:

    "Could not write value to key
    HKEY_CURRENT_USER\Software\Classes\.py Verify that you have
    sufficient access to that key, or contact your support personnel."

    ... Same for .pyw, .pyc, *.pyo etc.
    ... Python.File\shell\open\command
    ... Python.NoConFile\shell\open\command
    ... Python.CompiledFile\shell
    ... Edit with Idle

    and so on. I was just wondering if the installer should be aware of the
    rights situation and not try to write those keys in the first place.

    --
    Vincent

    > If not, in what way did that surprise you?
    >
    > Regards,
    > Martin
     
    vincent wehren, Aug 6, 2004
    #4
  5. vincent wehren wrote:
    > Well, writing a bunch of the registry keys fails. This user has no rights to
    > write them and is greated with several error messages as in:
    >
    > "Could not write value to key
    > HKEY_CURRENT_USER\Software\Classes\.py Verify that you have
    > sufficient access to that key, or contact your support personnel."
    >
    > .. Same for .pyw, .pyc, *.pyo etc.
    > .. Python.File\shell\open\command
    > .. Python.NoConFile\shell\open\command
    > .. Python.CompiledFile\shell
    > .. Edit with Idle
    >
    > and so on. I was just wondering if the installer should be aware of the
    > rights situation and not try to write those keys in the first place.


    This is very surprising. How unprivileged must a user be so he can't
    write to HKEY_CURRENT_USER? What operating system is this, and how
    was the user created?

    MSI does have the notion of unprivileged users, but those are the
    ones that can't write to System32, the All Users profile, and
    HKEY_LOCAL_MACHINE (i.e. non-Administrator, non-Power User users).
    There is no provision (AFAICT) for user that can't write to their
    own registry.

    Regards,
    Martin
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Aug 6, 2004
    #5
  6. Martin v. Löwis wrote:
    > vincent wehren wrote:
    >
    >> Well, writing a bunch of the registry keys fails. This user has no
    >> rights to
    >> write them and is greated with several error messages as in:
    >>
    >> "Could not write value to key
    >> HKEY_CURRENT_USER\Software\Classes\.py Verify that you have
    >> sufficient access to that key, or contact your support personnel."
    >>
    >> .. Same for .pyw, .pyc, *.pyo etc.
    >> .. Python.File\shell\open\command
    >> .. Python.NoConFile\shell\open\command
    >> .. Python.CompiledFile\shell
    >> .. Edit with Idle
    >>
    >> and so on. I was just wondering if the installer should be aware of the
    >> rights situation and not try to write those keys in the first place.

    >
    >
    > This is very surprising. How unprivileged must a user be so he can't
    > write to HKEY_CURRENT_USER? What operating system is this, and how
    > was the user created?


    This is on Windows XP Professional. This is a plain vanilla "limited
    user" created via the user accounts tool in the control panel.

    >
    > MSI does have the notion of unprivileged users, but those are the
    > ones that can't write to System32, the All Users profile, and
    > HKEY_LOCAL_MACHINE (i.e. non-Administrator, non-Power User users).
    > There is no provision (AFAICT) for user that can't write to their
    > own registry.


    Yes. That makes sense. So I checked the registry with regedit.
    "HKEY_CURRENT_USER\Software\Classes" seems - for whatever reason - to be
    busted for this particular user. At least I can't open it manually with
    regedit, so my tentative guess is the same applies to the installer.
    Sorry I didn't check this first!

    --
    Vincent Wehren




    >
    > Regards,
    > Martin
     
    vincent wehren, Aug 6, 2004
    #6
  7. vincent wehren wrote:
    > This is on Windows XP Professional. This is a plain vanilla "limited
    > user" created via the user accounts tool in the control panel.


    Ok. I will try that.

    There is a policy AlwaysInstallElevated, with which the administrator
    can allow limited users to perform installations:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/alwaysinstallelevated.asp

    If the computer is in a domain, this policy can be controlled through
    group policy.

    Regards,
    Martin
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Aug 6, 2004
    #7
  8. Martin v. Löwis wrote:
    > vincent wehren wrote:
    >
    >> This is on Windows XP Professional. This is a plain vanilla "limited
    >> user" created via the user accounts tool in the control panel.

    >
    >
    > Ok. I will try that.
    >
    > There is a policy AlwaysInstallElevated, with which the administrator
    > can allow limited users to perform installations:
    >
    > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/alwaysinstallelevated.asp
    >
    >
    > If the computer is in a domain, this policy can be controlled through
    > group policy.
    >
    > Regards,
    > Martin



    Martin, did you see my last remark in my previous post?:

    >
    > MSI does have the notion of unprivileged users, but those are the
    > ones that can't write to System32, the All Users profile, and
    > HKEY_LOCAL_MACHINE (i.e. non-Administrator, non-Power User users).
    > There is no provision (AFAICT) for user that can't write to their
    > own registry.


    Yes. That makes sense. So I checked the registry with regedit.
    "HKEY_CURRENT_USER\Software\Classes" seems - for whatever reason - to be
    busted for this particular user. At least I can't open it manually with
    regedit, so my tentative guess is the same applies to the installer.
    Sorry I didn't check this first!

    --
    Vincent Wehren
     
    vincent wehren, Aug 7, 2004
    #8
  9. vincent wehren wrote:
    > Yes. That makes sense. So I checked the registry with regedit.
    > "HKEY_CURRENT_USER\Software\Classes" seems - for whatever reason - to be
    > busted for this particular user. At least I can't open it manually with
    > regedit, so my tentative guess is the same applies to the installer.
    > Sorry I didn't check this first!


    Yes, saw that. I'm not faulting you though - I do believe that the
    behaviour in this case should be improved somehow.

    Regards,
    Martin
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Aug 8, 2004
    #9
  10. Martin v. Löwis wrote:

    > Yes, saw that. I'm not faulting you though - I do believe that the
    > behaviour in this case should be improved somehow.


    Ok, I have tried to reproduce this, and *now* I'm faulting you :)
    I thought that there was a special "restricted user" with less-than-
    reasonable permissions. I usually have XP Pro in a domain only, so I
    don't get to see this user interface. I have tried this out, and found
    that a "restricted account" is just one where the user belongs to
    the "Users" group (instead of belonging to the "Power Users" group).
    Such a user can, by default, write to its own registry, and install
    the MSI as planned (i.e. Privileged is false). Closing #1004837.

    Regards,
    Martin
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Aug 10, 2004
    #10
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anthony Baxter

    RELEASED Python 2.4, alpha 1

    Anthony Baxter, Jul 9, 2004, in forum: Python
    Replies:
    22
    Views:
    616
    Irmen de Jong
    Jul 16, 2004
  2. Mike C. Fletcher

    Re: RELEASED Python 2.4, alpha 1

    Mike C. Fletcher, Jul 9, 2004, in forum: Python
    Replies:
    16
    Views:
    521
    Mike C. Fletcher
    Jul 12, 2004
  3. Anthony Baxter

    RELEASED Python 2.4, alpha 2

    Anthony Baxter, Aug 5, 2004, in forum: Python
    Replies:
    0
    Views:
    267
    Anthony Baxter
    Aug 5, 2004
  4. Anthony Baxter

    Re: RELEASED Python 2.4, alpha 2

    Anthony Baxter, Aug 5, 2004, in forum: Python
    Replies:
    29
    Views:
    710
    Greg Ewing
    Aug 11, 2004
  5. Anthony Baxter

    RELEASED Python 2.4, alpha 3

    Anthony Baxter, Sep 3, 2004, in forum: Python
    Replies:
    0
    Views:
    328
    Anthony Baxter
    Sep 3, 2004
Loading...

Share This Page