3 ms·

I think the objection is not "old installers shouldn't be elevated" but that making the OS decide this based on the filename of the EXE is a disappointingly klu

I think the objection is not "old installers shouldn't be elevated" but that making the OS decide this based on the filename of the EXE is a disappointingly kludgey (but sadly unsurprising) way to do the job. One alternative might be to have a security framework that offered the UAC prompt when a program actually attempted to do something that required elevation. I had thought that was the way UAC actually worked. I wouldn't be surprised, given all the details, to learn that this "check the filename" approach really was the most sensible and appropriate thing to do at the time. We could call it a matter of "path dependency" if we're feeling charitable or a matter of "painting oneself into a corner" if we're not. What I find so fascinating and irritating at the same time, every time I hear about some bit of Windows internals like this, is that MS seems to need an exit from a corner they've painted themselves into all the time.

anonymfus 13y ago
>One alternative might be to have a security framework that offered the UAC prompt when a program actually attempted to do something that required elevation. I had thought that was the way UAC actually worked. This is how it works in most cases, but it's different with access to directories inside "Program Files" folder: because it was a common behaviour in the past, there is a such feature as UAC virtualisation: http://msdn.microsoft.com/en-us/library/bb756960.aspx http://msdn.microsoft.com/en-us/library/bb756960.aspx >Prior to Windows Vista, many applications were typically run by administrators. As a result, applications could freely read and write system files and registry keys. If standard users ran these applications, they would fail due to insufficient access. Windows Vista improves application compatibility for standard users by redirecting writes (and subsequent file or registry operations) to a per-user location within the user’s profile. For example, if an application attempts to write to C:\Program Files\Contoso\Settings.ini, and the user does not have permissions to write to that directory, the write will get redirected to C:\Users\Username\AppData\Local\VirtualStore\Program Files\contoso\settings.ini. For the registry, if an application attempts to write to HKEY_LOCAL_MACHINE\Software\Contoso\ it will automatically get redirected to HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso or HKEY_USERS\UserSID_Classes\VirtualStore\Machine\Software\Contoso.

anonymfus 13y ago

>One alternative might be to have a security framework that offered the UAC prompt when a program actually attempted to do something that required elevation. I had thought that was the way UAC actually worked. This is how it works in most cases, but it's different with access to directories inside "Program Files" folder: because it was a common behaviour in the past, there is a such feature as UAC virtualisation: http://msdn.microsoft.com/en-us/library/bb756960.aspx http://msdn.microsoft.com/en-us/library/bb756960.aspx >Prior to Windows Vista, many applications were typically run by administrators. As a result, applications could freely read and write system files and registry keys. If standard users ran these applications, they would fail due to insufficient access. Windows Vista improves application compatibility for standard users by redirecting writes (and subsequent file or registry operations) to a per-user location within the user’s profile. For example, if an application attempts to write to C:\Program Files\Contoso\Settings.ini, and the user does not have permissions to write to that directory, the write will get redirected to C:\Users\Username\AppData\Local\VirtualStore\Program Files\contoso\settings.ini. For the registry, if an application attempts to write to HKEY_LOCAL_MACHINE\Software\Contoso\ it will automatically get redirected to HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso or HKEY_USERS\UserSID_Classes\VirtualStore\Machine\Software\Contoso.