I saw a post on Slashdot titled "Coding Around UAC's Security Limitations", which pointed towards this.

The whole angle of the post on Slashdot is trying to make it seem that UAC doesn't do anything and is worthless, the iReboot developers certainly have that angle too, in what I'm sure some would call a childish tirade.

iReboot is an application that sits in the tray, and allows you to select an OS you want to reboot into. It does this by changing the boot loader so the OS you selected is the default and then rebooting the machine.

To modify the boot loader, you obviously need administrative privileges, this is a system-wide change and wrongly altered can render the system unbootable.

On Windows XP the iReboot application required you to be logged in as an administrator, for obvious reasons (standard users not having the rights to change the boot loader).

On Windows Vista, iReboot would also require administrative privileges to work. With UAC, even users logged in as administrators have their applications run as standard users, which is why applications need to elevate to run as administrators.

The developer goes on to write:

But there was one flaw in iReboot that made all the hard work we put into making it as unobtrusive and minimalistic as possible almost meaningless: if you had UAC enabled, iReboot will not run automatically at startup, no matter what you do.

iReboot could run automatically at startup with UAC enabled, the developer doesn't seem to be aware that you can write an application to ask for elevation. His application didn't - and so it just fails. Like it should. Obviously automatically starting an application and asking for elevation isn't a very good experience, which is why it shouldn't be done this way either.

I'm sure you all know that the Windows NT line (and other modern operating systems) has had the concept of "services". It seems the developer had to do some "digging around" for solutions, come on, any Windows geek knows how services work, this guy actually had to do research?

Services are usually started automatically by the system, for example the time service which goes out to the internet and corrects the time on your system. Changing the time requires administrative privileges, and as such the time service runs with administrative privileges. The same can be said about the 50 or so other services that run on the system.

He goes on to say:

only possible fix would be to split iReboot into two parts. One would run in the background as a service, running under the SYSTEM or LOCAL SERVICE accounts and having privileged access to the OS without requiring admin approval or UAC elevation, and with the second half running as an unprivileged userspace client program which interacts with the service backend to get stuff done.

This is also how it should be done on Windows XP, 2000 etc so that your application would work on standard user accounts, but it seems he doesn't care about standard users on Windows XP where he says "everyone runs as an Administrator", which isn't quite true. Others and myself have long tried to get people running as standard users on Windows XP, it is thanks to developers like this that kept people from running as standard users and greatly reduced the security of the world's computer base.

The developer then goes onto complain about how long all this took:

[G]etting this far wasn't easy. With Windows Vista, what should have been 100 lines of code maximum ended up being a dozen times longer, split across two different processes, and requiring way too much man-hours to write the most minimalist and to-the-point piece of software we've released to date.

Of course if the guy had bothered to look at the development guidelines and documentation that is almost a decade old now he would of seen this is how his application should of been written in the first place. Instead of him assuming he will have administrative rights forever, Microsoft have been hammering on about testing your applications as standard users for years and years before Windows Vista shipped, it isn't like they just pulled this out of the bag.

The developer then makes one final stab at UAC:

Perhaps most importantly though, is the fact that Windows Vista's newly-implemented security limitations are artificial at best, easy to code around, and only there to give the impression of security [his emphasis]. Any program that UAC blocks from starting up "for good security reasons" can be coded to work around these limitations with (relative) ease. The "architectural redesign" of Vista's security framework isn't so much a rebuilt system as much as it is a makeover, intended to give the false impression of a more secure OS.

Essentially claiming that UAC is worthless and can be coded around (by using services), which is false because in order for you to install that service in the first place you must elevate the installer, else it cannot create or modify the service.

Just today a new exploit was discovered in QuickTime (yes another one), with UAC enabled the exploit doesn't work. Because QuickTime isn't running as an administrator, but only as a standard user. Just another example of how UAC just gives the "impression" of security.