Hacker News Reader

Comment by mickeyp | Hacker News Reader

Of course it's hardcoded. In Vista and above you have to include a manifest file telling the OS whether you require elevation or not. In order to support old applications written pre-Vista, and to protect users against developers who don't care to learn how installers are supposed to work, Windows will force UAC if the file name sounds like something a setup program would call itself, particularly when most installers will install or modify things that require Admin privileges -- such as writing to Program Files.

This seems perfectly sane and reasonable to me. What's the alternative? That manifest-less installers should fail because a user forgot to manually elevate a program by shift-right clicking it and selecting "Run as Administrator", all because they upgraded their OS and now their installers won't run any more?

View on HN

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.

>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

>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.

One of the problems with it is there's no "don't run as administrator" right click option. Developers can add a manifest, there's some crazy sysadmin tools that aren't even installed with windows to suppress it, but ordinary users don't have an out--changing the filename doesn't help, the resources in the file still identify it as "setup.exe".

This is one of the things that makes user separation hard on windows, as anyone who wants to do anything vaguely useful with the computer still needs Administrator access.

It's a problem that simply naming a file 'install' or 'setup' would cause extra, unwanted behavior.

I guess it's similar to naming files PRN or NUL. You learn not to do that. It doesn't make it okay.

It's not unwanted. Not automatically elevating would break older installers written in a pre-Vista era, or written by developers who don't bother embedding a manifest telling Windows that it requires elevation. Imagine being a user upgrading from XP to Vista/7 and finding that all their old programs no longer install as they fail to write to Program Files -- something that you could get away with in older versions of Windows where people used admin privileges for everything. And yet that very problem would go away for almost everyone, everywhere, by simply elevating programs named setup or install. Seems like a perfectly sane way to make things backwards compatible.

It is unwanted, broken and stupid to hardcode policy behaviour on the filename of executables.

I lost a few hours to this because it's so quirky and easy to forget. This happened during the compilation of a certain library, which created an install.exe program to move files around the filesystem. That stupid UAC dialog was not even kicking-in and basically the copying just died.

Unwanted.

1) Write a little, one-off initialization script (I forget what it did -- probably copied a few files from point A to point B). Expect this task to take about five minutes.

2) Four hours later you discover that merely calling that stupid little script 'setup.cmd' caused all kinds of UAC havoc to ensue. Bang head against desk.

So, now I know. But it sure was counter-intuitive, and (I suggest) more than a little ham-handed on Microsoft's part.

Don't get me started about significant trailing spaces in environment variables (another little gift of non-intuitive behavior in the MS environment).

> 1) Write a little, one-off initialization script (I forget what it did -- probably copied a few files from point A to point B). Expect this task to take about five minutes.

The number of users who run legacy installers and expect them to work exceeds the number of users who write "little, one-off installation scripts" by several orders of magnitude.

And break Cygwin/MSYS/<*nix compat layer> that provides install(1).

Reply on news.ycombinator.com