Vista/7 install for non-admin user
in [Win32 API]
|
Prev: Listview trouble
Next: MFC and OpenGL in VS9
From: Bob Masta on 24 Feb 2010 08:35 Anyone know about creating installers that work with Vista/7 for non-admin user accounts? The problem is that if the app is to be installed to Program Files (and update Add/Remove Programs in the registry), it needs to have admin privileges. Unfortunately, with Vista/7 this seems to mean that the installer actually runs under the admin account. (In XP, it kept the current account.) Then if any user-specific files need to be installed to (say) Documents, they end up in the admin Documents instead of the user Documents. So far, I haven't found a work-around using NSIS, and haven't seen any mention of other installers that can handle this properly. But it seems like it should be a common issue, so what am I missing? Thanks, and best regards, Bob Masta DAQARTA v5.00 Data AcQuisition And Real-Time Analysis www.daqarta.com Scope, Spectrum, Spectrogram, Sound Level Meter Frequency Counter, FREE Signal Generator Pitch Track, Pitch-to-MIDI DaqMusic - FREE MUSIC, Forever! (Some assembly required) Science (and fun!) with your sound card!
From: Dee Earley on 25 Feb 2010 04:54 On 24/02/2010 13:35, Bob Masta wrote: > Anyone know about creating installers that work > with Vista/7 for non-admin user accounts? > > The problem is that if the app is to be installed > to Program Files (and update Add/Remove Programs > in the registry), it needs to have admin > privileges. Unfortunately, with Vista/7 this > seems to mean that the installer actually runs > under the admin account. (In XP, it kept the > current account.) > > Then if any user-specific files need to be > installed to (say) Documents, they end up in the > admin Documents instead of the user Documents. > > So far, I haven't found a work-around using NSIS, > and haven't seen any mention of other installers > that can handle this properly. But it seems like > it should be a common issue, so what am I missing? You can not reliably write into one users profile when running as another user (Windows security is specifically designed this way) Even if you could, it would only exist for one user and all others would find it missing. If you want the user to have certain files in their profile, copy on first run as that user, or provide two parts. Inno will allow both situations, but not really in the same setup (although one can be embedded in the other) -- Dee Earley (dee.earley(a)icode.co.uk) i-Catcher Development Team iCode Systems
From: Bob Masta on 25 Feb 2010 09:23 On Thu, 25 Feb 2010 09:54:53 +0000, Dee Earley <dee.earley(a)icode.co.uk> wrote: >On 24/02/2010 13:35, Bob Masta wrote: >> Anyone know about creating installers that work >> with Vista/7 for non-admin user accounts? >> >> The problem is that if the app is to be installed >> to Program Files (and update Add/Remove Programs >> in the registry), it needs to have admin >> privileges. Unfortunately, with Vista/7 this >> seems to mean that the installer actually runs >> under the admin account. (In XP, it kept the >> current account.) >> >> Then if any user-specific files need to be >> installed to (say) Documents, they end up in the >> admin Documents instead of the user Documents. >> >> So far, I haven't found a work-around using NSIS, >> and haven't seen any mention of other installers >> that can handle this properly. But it seems like >> it should be a common issue, so what am I missing? > >You can not reliably write into one users profile when running as >another user (Windows security is specifically designed this way) >Even if you could, it would only exist for one user and all others would >find it missing. Agreed, which is why it is so mystifying that Microsoft would have changed from simple elevation in XP to actual account switch in Vista/7. After all, the Standard User account has just entered an Admin password to be able to install the app... why, oh why would Microsoft want to grant him the ability to mess with the Admin's private folders? Why not just elevate his privilege level to allow him to install the app for his own account? It seems that the new Vista/7 UAC approach is *less* secure, not more. What were they smoking in Redmond? >If you want the user to have certain files in their profile, copy on >first run as that user, or provide two parts. >Inno will allow both situations, but not really in the same setup >(although one can be embedded in the other) > Yeah, I am aware of the 2-part installer trick; a similar "fix" is available for NSIS. What a kludge! You'd think with all the Microsoft talk about how everyone should run at the lowest privilege level, they wouldn't make it so needlessly hard to do. (Grumble, grumble...) ;-( </rant> Best regards, Bob Masta DAQARTA v5.00 Data AcQuisition And Real-Time Analysis www.daqarta.com Scope, Spectrum, Spectrogram, Sound Level Meter Frequency Counter, FREE Signal Generator Pitch Track, Pitch-to-MIDI DaqMusic - FREE MUSIC, Forever! (Some assembly required) Science (and fun!) with your sound card!
From: Dee Earley on 25 Feb 2010 11:44 On 25/02/2010 14:23, Bob Masta wrote: > On Thu, 25 Feb 2010 09:54:53 +0000, Dee Earley > <dee.earley(a)icode.co.uk> wrote: >> You can not reliably write into one users profile when running as >> another user (Windows security is specifically designed this way) >> Even if you could, it would only exist for one user and all others would >> find it missing. > > Agreed, which is why it is so mystifying that > Microsoft would have changed from simple elevation > in XP to actual account switch in Vista/7. After > all, the Standard User account has just entered an > Admin password to be able to install the app... > why, oh why would Microsoft want to grant him the > ability to mess with the Admin's private folders? Erm, XP didn't have elevation of any form, it ran as an admin user (if required) Vista and Windows 7 does exaclty the same for non admin users, the setup will end up running AS the admin user. The Change in Vista and 7 is that "admin" users don't have full admin access until they elevate (UAC). After elevation, they are still that same admin user, but have full access. > Why not just elevate his privilege level to allow > him to install the app for his own account? Non admin users won;t have this privilege hence needing to run as someone that does. > It seems that the new Vista/7 UAC approach is > *less* secure, not more. What were they smoking > in Redmond? How is it less secure? You can't get admin access unless you enter admin detaisl and run as said admin user. >> If you want the user to have certain files in their profile, copy on >> first run as that user, or provide two parts. >> Inno will allow both situations, but not really in the same setup >> (although one can be embedded in the other) > > Yeah, I am aware of the 2-part installer trick; a > similar "fix" is available for NSIS. What a > kludge! > > You'd think with all the Microsoft talk about how > everyone should run at the lowest privilege level, > they wouldn't make it so needlessly hard to do. > (Grumble, grumble...) ;-( It's not hard, it is the default state of any user and their processes. What you can't do is drop the privileges once you have them which is why Inno first runs as the current user, then elevates a second copy of itself to do the actual install. Unfortunately, this unelevated part is limited to running executables. Windows Installer (MSI) does similar, but only elevates during the actual install phase (as they have far more controlled access to code and the data to be installed) so can still install (current) user specific files. This is still a bad idea as if another user runs it, they won;t have the user specific data and depending on usage, can fail. -- Dee Earley (dee.earley(a)icode.co.uk) i-Catcher Development Team iCode Systems
From: Bob Masta on 26 Feb 2010 08:13
On Thu, 25 Feb 2010 16:44:34 +0000, Dee Earley <dee.earley(a)icode.co.uk> wrote: >On 25/02/2010 14:23, Bob Masta wrote: >> On Thu, 25 Feb 2010 09:54:53 +0000, Dee Earley >> <dee.earley(a)icode.co.uk> wrote: >>> You can not reliably write into one users profile when running as >>> another user (Windows security is specifically designed this way) >>> Even if you could, it would only exist for one user and all others would >>> find it missing. >> >> Agreed, which is why it is so mystifying that >> Microsoft would have changed from simple elevation >> in XP to actual account switch in Vista/7. After >> all, the Standard User account has just entered an >> Admin password to be able to install the app... >> why, oh why would Microsoft want to grant him the >> ability to mess with the Admin's private folders? > >Erm, XP didn't have elevation of any form, it ran as an admin user (if >required) >Vista and Windows 7 does exaclty the same for non admin users, the setup >will end up running AS the admin user. In XP, if a standard non-admin user runs the installer, it can install to Program Files, write the registry, etc. But it does not run AS the admin... it writes to the user's Documents, not the admin's. The user has admin privileges without assuming his identity. >The Change in Vista and 7 is that "admin" users don't have full admin >access until they elevate (UAC). >After elevation, they are still that same admin user, but have full access. > >> Why not just elevate his privilege level to allow >> him to install the app for his own account? > >Non admin users won;t have this privilege hence needing to run as >someone that does. > >> It seems that the new Vista/7 UAC approach is >> *less* secure, not more. What were they smoking >> in Redmond? > >How is it less secure? >You can't get admin access unless you enter admin detaisl and run as >said admin user. Think of this like valet parking. The valet (standard user) needs to be able to drive your car, but he doesn't need access to your trunk or glove compartment. You (admin) give him a "valet key" that works in the doors and ignition, but nothing else. He can get the job done, but not mess with your personal stuff. Under the Vista/7 scheme, you have to give the valet your whole key ring... home, safe deposit box, everything. The XP system only grants the needed access, not the whole identity. It's not only safer for the admin (whose folders might get changed inadvertently), it's better for the user since he can install properly to his own folders. >>> If you want the user to have certain files in their profile, copy on >>> first run as that user, or provide two parts. >>> Inno will allow both situations, but not really in the same setup >>> (although one can be embedded in the other) >> >> Yeah, I am aware of the 2-part installer trick; a >> similar "fix" is available for NSIS. What a >> kludge! >> >> You'd think with all the Microsoft talk about how >> everyone should run at the lowest privilege level, >> they wouldn't make it so needlessly hard to do. >> (Grumble, grumble...) ;-( > >It's not hard, it is the default state of any user and their processes. >What you can't do is drop the privileges once you have them which is why >Inno first runs as the current user, then elevates a second copy of >itself to do the actual install. >Unfortunately, this unelevated part is limited to running executables. > >Windows Installer (MSI) does similar, but only elevates during the >actual install phase (as they have far more controlled access to code >and the data to be installed) so can still install (current) user >specific files. > >This is still a bad idea as if another user runs it, they won;t have the >user specific data and depending on usage, can fail. All that is needed is to allow elevation (access to Program Files and registry) without identity change. This really only comes down to which shell path is used for certain folders. Vista/7 "knows" the identity of the original user, because it does write to the user's Start Menu and Desktop properly. (Although it does write to admin as well.) It just refuses to use the user identity for folders like Documents. Since the elevation is already in place, there is no reason it couldn't do this. (As it did in XP.) Note that this would *not* be a violation of the original philosophy of not writing to another user's folders. It's the user writing to his own folders. Best regards, Bob Masta DAQARTA v5.00 Data AcQuisition And Real-Time Analysis www.daqarta.com Scope, Spectrum, Spectrogram, Sound Level Meter Frequency Counter, FREE Signal Generator Pitch Track, Pitch-to-MIDI DaqMusic - FREE MUSIC, Forever! (Some assembly required) Science (and fun!) with your sound card! |