Just about everyone using Windows XP runs the operating system as administrator – or root, if you come from a UNIX background. Such is the case because Microsoft, in its infinite wisdom, figured it somehow made sense to give every user full access to the system, and to more or less completely ignore the intricate and advanced security systems in place in Windows NT and the NTFS file system. This kind of turned out to be a very bad idea, and allowed Microsoft and its 3rd party developers to become hopelessly sloppy; most Windows applications more or less assumed they were run by administrators. It also allowed malware full access to the system when executed. Cue User Account Control.User Account Control was introduced in Windows Vista as a means to forcefully wake up application developers and users. Even though the first user created on a Windows Vista system is still a member of the Administrators group, this user’s privileges are severely limited due to the fact he or she receives not one, but two tokens. They share the first token with a normal, non-admin user: it contains all the basic privileges. The second token contains elevated privileges. This user’s applications are started with the first, restricted token, while applications that are granted admin rights (clicking “yes” in the UAC dialog) will be started using the second, unrestricted token. Kenny Kerr explains it better than I do, by the way.
The point is that with UAC, normal users and administrators alike are made aware of any potential security threats; applications that mean harm have to explicitly receive elevated permissions by the user. Therefore, turning UAC off is generally a bad idea (especially since it also disables the sandbox Internet Explorer 7 runs in). I hate to break it to you, but security is annoying. I find it annoying to lock the doors of my house and car every night, and open them again the next morning – however, I still do it, because I don’t want to have my gear nicked. Eventually, programmers will get used to UAC, and will cease making applications that assume admin privileges (and therefore, create a lot of UAC dialogs). This may take some time, but they’ll get there.
Microsoft also prohibited applications that require elevated permissions from running when the user logs on. The reasons were explained on the UACBlog back in August 2006:
Without blocking applications from prompting for elevation in the user’s logon path, both standard users and administrators would have to respond to a User Account Control dialog box on every log on. While this potentially becomes an annoyance for administrators, it is an unusable UI for standard users who cannot drive the UAC elevation prompt without having an administrator around to provide credentials. Furthermore, we advise users to be wary of prompts that appear without them taking an explicit action – and prompts generated at startup go against that advice.
However, there are a few ways to get around this limitation. The first is using the Task Scheduler to launch the application in question. The second is to split the application in two parts; a system service running under the SYSTEM
or LOCAL SERVICE
accounts so that it has full system access, and a normal application that interacts with that service and directs it to do the things that required the admin privileges in the first place.
And that is exactly what the guys at NeoSmart Technologies did in order to get their application iReboot to run like they think it should. iReboot is a little program that lives in your system tray that allows you to select which operating system your computer should boot into upon the next reboot. It does this by modifying the boot entry that is marked as default in BOOT.INI
(Windows XP) or the BCD (Windows Vista). Both actions obviously require elevated permissions. Before this change, iReboot on Vista had to be started manually, or you needed to resort to the Task Scheduler option.
From this, the guys at NeoSmart end up at the following conclusion:
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. 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.
That’s a pretty bold conclusion – overly bold, if you ask me. The decision to block applications that need elevated permissions from running at logon was not a security decision, but a usability decision, as the quote from the UACBlog at the beginning of this item explains. On top of that, UAC does, in fact, act as a security barrier with iReboot. You see, installing the application obviously still requires elevated permissions to install its two parts – it has already passed UAC during installation. So, the issue here seems that Windows lacks a method of informing users a new system service is being installed.
I try to limit the amount of applications on my system that need to install system services in order to function properly, or that even just install unnecessary services without my consent (QuickTime and iTunes, for example). I regularly load services.msc
and msconfig
to disable services that come with applications.
Willingly relinquishing control over your bootloader to a system service that doesn’t come straight from Microsoft seems utterly alien to me. Bootloader files should be properly protected and should not be easily accessible. What if a bug in iReboot’s system service renders your BCD or BOOT.INI
corrupted?
The thing with the bootloader is that MS has always liked to pretend that no other intel-based pc operating systems exist. Vista is the first time we have seen something from them more fully featured then the incredibly primitive NTLDR, and even though BCD has a lot more features, it still lacks any real tooling (third parties have filled this space though).
It seems like their attitude is/has been that this is one of those areas they don’t recommend/support people messing with, although they will give the tools if you really really want to. I would expect if they ever gave us a GRUB level bootloader, it would be accompanied by access control tools.
And being allowed to control what account your service is running under is expected behavior, and I don’t see how that would be considered a circumvention of UAC. That is like saying that UAC is purely cosmetic, since anyone can just stick a boot disc in and format the HD anyways. Hard to believe anyone could have the level of knowledge to be able to write something like iReboot, and still be that much of an idiot.
Edited 2008-04-27 18:41 UTC
UAC is a nightmare. In my experience, building Vista was horrible: I got UAC prompts all the time, sometimes just seconds after the last prompt. It didn’t give me a few minutes of elevation, it just flat out required manual okaying over and over. Furthermore, the prompt moved all over the screen, further annoying me. I’m told this is to prevent an application from “clicking” a predictable area of the screen, but it makes it even more frustrating.
UAC is poor and mostly annoying design. Microsoft relies on lock-in to stay relevant. If if they were smart, they’d go back and properly redesign userland and interaction with the kernel to allow for proper security.
And for those interested, UAC can be “muted” so that it’s still on and IE still runs in its sandbox, but the prompts never show up.
What confuses me is that they got the greatest minds to work on the kernel then the royally screwed the whole operating system up by choosing to have the half baked win32 as their default API for everything to be built on. Then again, this is what happens when you allow politics and marketing to decide the fate of a product than knuckling down and address customers needs.
You’re right about a redesign, but I don’t think it needs to be totally ‘chuck everything out’ – sure, keep the kernel, pull out the stuff that was added in to keep Bill Gates happy – then rip off win32, implement a UNIX 2003 certified implementation ontop followed by a great GUI. If a small company like Apple can do it, so can Microsoft.
You’ve written the recipe for completely ending Microsoft’s domination on the desktop.
If you rip out the Win32 API, you force the majority of Windows applications to be rewritten from the ground up. Keep in mind that many large software packages have code bases that go back many years, hence they have been reluctant to leave the Win32 API behind and jump onto the .NET bandwagon. Rewriting an application is no small undertaking and the ROI needs to be carefully weighed.
Bear in mind that while the majority of Windows desktop applications are Win32, nobody has anything good to say about that API or the assorted wrappers like ATL/MFC/WTL. If Win32 support is pulled, what’s most likely to happen? Applications will be rewritten but they will most likely ignore anything that Microsoft comes up with, preferring instead a toolkit like Qt or wxWidgets which is crossplatform. I know that’s what I’d do if I was asked to rewrite the project I’m currently maintaining. _All_ other programmers I know would seriously consider cross platform APIs if asked to start a project from the ground up. Cross platform APIs means that applications run on multiple platforms. If apps are available on multiple platforms, the need for Windows suddenly diminishes.
If Microsoft pulls Win32 support, they will end up leveling the playing field for all other alternative operating systems (Linux, OS X, etc). They know this, and that’s why Win32 support will never ever go away.
So they’re pretty much stuck in a catch 22 – the again, they could do the radical redesign, or atleast UNIX 2003 + Win32 with all the nasty bits taken out (aka Carbon) and everything else running inside a virtual machine. Sure, it wouldn’t be nice, but I’m sure Microsoft is capable of it.
I mean, look at the ROI of not moving in the case of many software companies – talk to any programmer who has to deal with win32 on a regular basis – its a miracle that a person can write anything for Windows let alone for the application to run in a reliable fashion.
My favorite thing is the prompts warning you that you are about to be prompted for escalation.
IMO UAC is almost perfect and shouldn’t be touched for Vista Business, and Server 2k8. The only thing that bugs me is that you should be able to save the user name of the last credentials you used. At work, we have local admin accounts, but normal domain accounts. It is very irritating to have to type .\full.name.admin every single itme.
For Vista basic, premium, and ultimate, the grey screen, jumping box locations, and the “warning” prompts should all be dropped, and the whole ACL thing should be simplified to something closer to the unix-y way of things. What would be nice is allowing for user specific program installation, but at the least, .\Users should have write permissions on C:\Program Files.
The first would eliminate the irritating nature of the prompts, the second would eliminate ~80% of them. You don’t need that level of security measures on a home pc, and by the all or nothing approach MS gave UAC, they are just going to drive people to disable the whole thing, which is the opposite of why it was made in the first place.
this is BAD, because in this way a virus or a malicious user can replace any arbitrary executable file in c:\program files.
In Vista this folder C:\Program files is protected in order to ensure nobody can modify the installed programs (to write in this folder you must have administrative privileges; Windows Explorer allows you to modify these files via UAC elevation request)
Edited 2008-04-28 09:29 UTC
Yeah, it is not ideal. I should have worded it better, what I meant was that the ideal would be that they allow for user specific software installation like apple does. That would mean a lot of breaking change though, so if they don’t do that, simplify the security paradigm to something along the lines of the UNIX security scheme, so at least normal people have a chance in hell of understanding it.
IF neither of those are possible, then give write access to program files. Sure, a virus can replace any executable there, but a virus that is successfully running already has access to all your data, and on a single user machine that means more then your programs anyways. By giving write access to Program Files, it would eliminate alot of the “noise” that UAC generates, which would mean that people would be less likely to turn it off, and more likely to pay attention to it.
Hmmm… Still think I’d prefer not to give write access to Program Files to everybody.
Example:
A virus is launched, but it is launched from IE 7 (which means it will be running at a level even lower than a standard user).
In this example, the virus would *not* have access to any of my data.
I wouldn’t want *that* having access to Program Files…
A better solution would be to virtualize the O/S per user, i.e. let the user play with the c:/windows folder, but in reality he would play with a copy of the folder, thus not allowing the system to be messed up.
I’d love to know what you were doing to cause that, because I’ve never seen UAC more than once within a reasonable period of time.
In fact, I’ve never had more than one UAC prompt in a row unless it was completely unrelated to the first (i.e. opening Computer Management and IIS at the same time will cause two, but they are different programs so it’s OK).
In fact – I think it’s actually dangerous to “keep admin going for a minute” to prevent more than one popping up… This “safe minute” is exactly when that hidden trojan wreak its havoc…
You gotta remember that it’s designed to stop grandma from installing a virus accidentally.
Ordinarily, grandma will never see it when she’s checking her email, browsing the web, drawing a picture, playing a game or writing a letter (which probably covers most of what she wants to do).
It all comes down to the user. If you are a completely confident and competent IT professional, then by all means – turn it off if you’re happy to do so.
“Such is the case because Microsoft, in its infinite wisdom, figured it somehow made sense to give every user full access to the system, and to more or less completely ignore the intricate and advanced security systems in place in Windows NT and the NTFS file system. This kind of turned out to be a very bad idea, and allowed Microsoft and its 3rd party developers to become hopelessly sloppy”
Speaking of sloppy, how about sloppy journalism. Nobody forces you to run as Admin when you create a new user account in XP. Hell, all the way back to NT 4.0 I created and ran as a limited rights user. Microsoft created a system that allowed you to run with whatever level of privileges you wanted, and supported very fine grained access control over the file system and a number of other system services.
The fact that vendors chose to release software that required administrative privileges to install, and even to run (!) has nothing to do with Microsoft. The software vendors were sloppy because users didn’t care. And vendors don’t spend money coding features that users don’t care about.
Except for the fact that during installation of Windows XP, the first created user is ALWAYS an admin, whether you like it or not. You can only change that afterwards, but you can’t expect a normal user to do that.
If you want to go smartass, it’s best to have your facts straight. Else it kind of doesn’t come across.
Apart from the above, some of Microsoft’s apps even do not respect the admin privileges thing.
So which is it:
“figured it somehow made sense to give every user full access to the system”
or
“the first created user is ALWAYS an admin, whether you like it or not”
Is it the first user, or every user?
Whilst it is true that you could create user accounts and try and use your computer that way, as I recall (haven’t used xp in a while) fine grained control over access rights was only found in professional version.
Strange how everybody used admin instead of user accounts … oh yeah because it was default and most users are idiots when it comes to security so people just created admin accounts.
Those that tried with simple user accounts often found that they couldn’t install programs so they just wouldn’t bother with user accounts.
True, but there are really many apps that won’t run without admin privileges. You can adjust things like registry / directory permissions and a few will finally make it, but the typical XP “always admin” user does not know how to do these things.
It does. They have been silently promoting this “all admin” stuff. They have been certifying all kind of third party apps with their “designed for XP”, “compatible with XP” logos, and most of these would only run as admin. In fact, they were doomed from the start: XP had to maintain Win9X compatibility (lots of people went straight from 98 to XP, without going through NT or 2000) and 9X had no concept of user levels or permissions. Now they have to hack their way into the secure mode, with UAC, “the not so admin-admin” etc. They will get there eventually. This is a transition phase.
I used XP Pro with limited user for a year on a laptop and it was a freaking nightmare. You can’t even change the powersaving policies in a limited user without promoting them to Administrator first and putting them back down afterwards. I also had lots and lots of weird File-ownership Problems, having to copy files to another location and back again before i could execute them as my limited user.
So, yes, it is possible to run XP Pro as a limited user and there is even some software around that still more or less works then but it doesn’t work very well and is so much pain that most user wouldn’t want to use it that way.
Now i use Windows only to push mp3 to my crappy sony player, when that is replaced (by a non crap/sony player) I’ll say my last goodbye to Windows… Linux and OS X just are so much less trouble and pain.
Offtopic, but if you like the design and build of Sony players, you don’t have to give up on them. Their new players don’t require Windows.
Well i wont ever get an Sony player again. Not only because their horrible software but also because the players don’t work that well. They are barely useful for listening to podcasts or other very long types sound files as fastforeward is unusable slow and you can’t create bookmarks within the file. Granted, if you pause or shut down it will continue where you left, but if you accidentally skipped or did a recharge that is lost as well. Also, i couldn’t get my dutch learning mp3s onto my Sony Walkman, despite having enough space… they just kept disappearing or i got the “error” error message which doesn’t tell you what went wrong.
Another thing is the silvery finish of those players… it is pretty, but it makes it impossible to use in daylight.
If all that wasn’t enough, i doubt anyone will ever trust them again after the ATRAC debacle.
About that though, aside from the DRM, ATRAC is acoustically superior to MP3, WMA, OGG. Sony’s policies may suck, but their technology is always of the highest level.
SOny would like you to believe that, and tests founded by Sony indeed support that claim (sounds familiar?). But not independent ones – definatelly AAC or Vorbis are superior in this case. (sorry, would have to browse through hydrogenaudio tests archive, would be hard on mobile…)
Alleister wrote:
-“used XP Pro with limited user for a year on a laptop and it was a freaking nightmare. You can’t even change the powersaving policies in a limited user without promoting them to Administrator first and putting them back down afterwards.”
while certain per-user settings (such as energy settings) require administrative rights (or atleast priviledged user rights), for most stuff like installing/running software etc that require administrator or priviledged accounts you can simply use shift + right-click to bring up the ‘Run as’ context menu and run the application with the chosen account priviledges without having to log out of your current unpriviledged account.
I haven’t run windows as anything but unpriviledged user for my day to day work ever since I bought win2k way back. also, it was a looong time since I actually encountered any programs that needed administrator priviledges while running them, although alot of programs still require administrator rights when installing, which is due to arcane copy-protection mechanisms which ironically probably only plagues those of us who actually purchase our software.
Well, i used runas in that time a lot, but that didn’t help with the energy settings, since you then change the settings for the other account.
That also didn’t help with the weird file ownership problems.
I think the Problem is that the developers at Microsoft use Windows the same way as the huge majority of their customers… with administrative rights. I can’t explain those obvious problems with it otherwise apart from them maybe being sadistic.
Try this:
runas /user:Administrator “control powercfg.cpl”
(Replace “Administrator” with the administrator’s account name).
Works for all control panels – just need to find the corresponding .cpl file in WINDOWS\SYSTEM32.
djhayman wrote:
runas /user:Administrator “control powercfg.cpl”
(Replace “Administrator” with the administrator’s account name).
Works for all control panels – just need to find the corresponding .cpl file in WINDOWS\SYSTEM32.
yes, that is the commandline version of the ‘Run as’ context menu. however, the problem remains the same. you will alter the per-user settings of the energy policies, so in this instance you will change the administrator’s energy policies rather than that of the user account you are running. like someone said earlier, in order to change your energy settings for an unpriviledged account you will have to bump the rights of that account temporarily, set the energy policies, and then change it back to unpriviledged. it would seem smarter to either let administrator handle the energy policies for all users, or let each user set their own policies regardless of priviledges.
that said, I don’t change my energy policies very often (read, once after install) and as such this is not a big problem for me.
Hmmm… I see. Never tried it specifically for that, so my bad 😉
What about the “runas” command line argument “/env”?
“/env to use current environment instead of user’s.”
Has anybody tried this?
Reading that description, it sounds like it uses the current environment (i.e. runs it as the current user), but gives it the privilege level of the specified user…
djhayman wrote:
–“What about the “runas” command line argument “/env”?
“/env to use current environment instead of user’s.” “
I’ve tried that before with no success, but I gave it another shot and nope, both with and without ‘/env’ it sets the power policy for administrator and not for the user account i’m logged in as :/
I have a different experience here. I have been running XP as a non-privileged user without problems for years. Only very occasionally I need to run some installation as Administrator (which sometimes indeed implies setting the file permissions correctly on the config files), but for everyday use (both professional and leisure) I had no problem whatsoever. The only glitch is indeed the power settings, which don’t switch automatically when you plug/unplug the power, but that is a minor issue for me. A very small price to pay for the substantial extra security. And BTW, also laptops used by non-techies with the same setup have caused no problems.
Using a PC as Admin all the time is just plain bad practice.
This problem can be solved by making some changes in the registry as described here:
http://blogs.msdn.com/aaron_margosis/archive/2005/02/09/370263.aspx
I’m not quite sure what the problem was in this case but the important thing to remember is that, when copying files, the permissions will change according to the policy defined by its parent folder (or an ancestor thereof).
However, when moving files, the original permissions will be retained unless they are being moved from one NTFS filesystem to another, in which case the behaviour is as that of copying.
I sometimes forget this when moving Start Menu shortcuts from the Administrator user profile to the Everyone user profile (installers that don’t install shortcuts for “everyone” … one of my pet gripes!). This sort of problem can be solved by using the “Replace permissions entries on all child objects …” checkbox in the Advanced Security Settings dialog.
Basically, if in doubt, it’s best to copy prior to deleting the originals.
Agreed in so far as “most user” doesn’t refer to the kind of person that regularly reads sites such as osnews.com
Seeing as I’m on the topic, I might as well also convey two tips that I find quite useful. One is to set up an administrative command prompt shortcut:
%SystemRoot%\system32\runas.exe /user:administrator %SystemRoot%\system32\cmd.exe
This is useful as a launchpad for other processes that needed to be started in an administrative context, including some control panels (try running dir /w *.cpl immediately after opening such a prompt). Furthermore, one can drag and drop icons into the window of the command prompt – particularly useful for starting things that do not offer a “Run As” option (such as MSI installer packages).
The other tip I wanted to convey is that by enabling the “Restrict CD-ROM access to locally logged-on user only” security option via gpedit.msc, it is possible to rip and burn optical media as an ordinary user. This doesn’t appear to be widely documented but is one of the first things that I change after installing Windows.
If i remember correctly visual studio gives uac popups. Encourage programmers to use proper access right is a really good idea. Making it obnoxious for the end user is bad. Making it obnoxious for the enduser in your own programs is a real wtf?
oh, and for everyone complaining about needing admin rights in xp : use “runas.exe” (sortof su/sudo). it’s not grandma proof, but grandma’s should not be admin anyway.
Edited 2008-04-27 22:44 UTC
…and what happens when Grandma wanted to install something? “Oh yeah, Grandma…right click the file, choose ‘Run As’ type in this password and hope it works.”
Personally, MS ‘Run As’ is/was a joke. I’ve never gotten the stupid thing to run _anything_ the way it would as local admin. It was a useless “me too” feature that Microsoft is so good at trying to pass off as price filler.
You mean like a trojan?
Just go on and try to change the energy settings of your XP notebook with runas… you will get the same good laugh as i did.
I’m currently splitting some apps we develop at work into services and userland applications. Vista does certainly enforce you to write more well designed programs.
All those complaints about UAC being annoyed are an effect of Windows apps being badly written. You can draw a very crude and technically innacurate comparison between graphical sudo frontends and UAC, from the users pont of view. Apart from the much more complex security infrastructure present in Windows NT-based systems and the fact that the way UAC prompts for user authorization is more secure than those programs, they serve the same purpose: give temporary elevated rights to programs after user authorization. It’s actually more complex than that, but let’s keep things simple here. The problem is that too many Windows apps require those elevated rights, that’s why people complain about UAC but don’t complain about those graphical sudo frontends installed in desktop-oriented Linux distributions.
Now regarding the issue of being able to run services as LOCAL_SYSTEM without an UAC prompt (other than the prompt required to install the service), the same can be said about Linux daemons installed by a program ran through sudo. Perhaps a better implementation would require the programs to state all their security requirements (needs to install a service, needs to write to some registry key, etc.) before doing anything, so that the user could be presented with that information in a single UAC prompt. Maybe that’s possible with UAC already, I don’t know the UAC API. Anyways, it would certainly take some time to modify all apps the regular user uses to comply with that.
The way I see it, UAC is not in the list of Vista features that Microsoft will consider removing, crippling or deprecating for the next Windows versions.
I’m no security expert by far, so take my words with a grain with salt.
Edited 2008-04-27 23:18 UTC
…
Edited 2008-04-28 00:46 UTC
Umm, not on my Slackware Linux system.
I work as a regular user without the OS getting in my way.
I don’t get any idiotic warnings with a dimmed screen when I try to edit my application menu or delete an icon from my desktop.
And when I do maintenance on my system, installing updates or new software, I log in as root or as su with one time password entry and go about my maintenance work without any interruptions.
Only a highly incompetent imbecile could come up with a system like Windows UAC.
UAC is beyond stupid and ridiculous, it’s an act of desperation.
Security isn’t annoying on your slack box, because you a.) you’re a linux master since you use that distro, and b.) you likely don’t use a lot of Windows apps. The rest of the world has to deal with it.
The guys at NeoSmart are obviously an excellent example of the sloppy Windows developer who doesn’t understand security one bit.
If you design your elevated service in such a way that anyone can access it then, surprise surprise, anyone can access it! Holy shit batman! The sky is falling!
In related news, if you give someone the keys to your car they can use it. Complain to your car manufacturer immediately and tell them the door locks are not working.
Thanks for posting your thoughts on the iReboot guys’ observations about UAC. Interesting, and provocative of discussion.
I don’t use Vista, but half the concerns here are tradeoffs made by every OS.
I mean complaining about needing admin rights for power-savings? That is definitely something that should require admin rights. I know it does in Ubuntu. So does changing the resolution and a host of other activities.
Heck in Ubuntu (which I use), so many things require SUDO. Sometimes I just want to check stuff(not change things) and it requires a sudo. They’re addressing with their new user account permission thing in Hardy, which looks promising, but it is hardly perfect I think it is the way to go though. just needs to be tuned nicely.
I also find this whole tale of the bootloader a little strange. I mean, editing the boot config is a dangerous operation. If you messed up that file, serious things would follow. It is definitely an admin thing and since it runs at startup (acting like a service)…maybe it should just run as a service…which they were forced to anyways.
I mean how many apps are actually like this IReboot ap. I certainly don’t have any.
Edited 2008-04-28 17:33 UTC
Incorrect. You dont need admin rights to change the powersaving settings in Ubuntu (or any other modern Linux I know of).
And neither does changing the resolution.
really?
I’m at work now or I would have checked.
I’ll take your word on that one
Apologies.
I’ll change my post above.
Edited 2008-04-28 17:58 UTC
It’s a little more complex than that. IMO, it was largely a case of Microsoft taking the path-of-least-resistance in terms of compatibility between Win9x and WinNT. The majority of Win32 software (pre-XP, at least) was written for Win9x – and since Win9x was effectively single-user, most Win32 apps were written to assume a single-user OS.
The side-effect was many of those apps did things that were the sole domain of admin users, in NT at least, meaning they would only work as an admin under NT-based OSes.
So, that effectively gave Microsoft two choices: make NT smart enough to ask the user to authenticate as an admin in order to carry out tasks that the user doesn’t have permissions to carry out – or just make all new users admin by default (the direction they ultimately chose, starting with 2k Pro).
The difference is that locking your doors at night / when you’re out has a practical, easily-defined purpose. IMO, the same cannot be said for many of UAC’s behaviours – E.g., what’s the practical purpose of asking users to enter the admin password to change time/date settings?
I’m all for setting the record straight on some of the uninformed anti-Microsoft hyperbole that gets flung around here. But, IMO, UAC is not defensible in any way, shape, or form.
The thing that I find most frustrating about UAC is that it would have taken such a small number of changes to make it feasible for “Average Joes” to use plain ‘ol XP as a non-admin user. The only problems were in terms of the user interface – if you were running as a normal user in XP/2k and tried to do something that required admin privs., you just got a “permission denied” error. I’m not OS engineer, but I can’t imagine it would have been rocket science to make a “Run as” dialogue appear instead of a “permission denied” error.
With UAC and Vista, I think they’ve continued the problem – just in a different way. With 2k/XP, it was too annoying to run as a normal user – so everyone just ran as an Admin, completely circumventing the OS’ security model. And with Vista, UAC is so annoying that a large number of users turn it off completely – again, circumventing the OS’ security model (at least, if the popularity of “How to disable UAC” articles is any indication).
It would be hard to make permission-denied turn into a elevation prompt for a number of technical reasons. Consider this simple one: an app is launched as non-admin and uses the ‘access denied’ error codes to figure out what it can or cannot do and works around it by reading/writing an alternate location. Do you choose to prompt the user and grant the app permission, which perhaps the author intended to just not use if unavailable, or do you leave the behavior as-is?
UAC is more than just an annoying security prompt (or sudo). There are also shims involved with UAC that silently redirect actions from programs that do not actually need admin rights to function correctly. Without these ‘heuristic’ mitigations, there would be far more prompts and annoyance than there is now. UAC, and Vista in general, is a kind of painful step needed to break with some of the past and create a system that will last for a while longer.