A Fresh Look at Vista's User Account Control

Art Grimm writes to mention a post at Ed Bott's Microsoft Report on ZDNet. There, he talks about Vista's User Account Control, and the issues he sees with the setup as it exists now. From the article: "The UAC prompts I depicted in the first post are those that appear when you install a program, when you run a program that requires access to sensitive locations, or when you configure a Windows setting that affects all users. But as many beta testers have discovered, UAC prompts can also show up when you perform seemingly innocent file operations on drives formatted using NTFS. In this post, I explain why these prompts appear and why some so-called Windows experts miss the obvious reason (and the obvious fix)."

Comments

How annoying

[kimvette]

Could they possibly make that "article" any more annoying? They'd have been better-served to turn it into a flash-animated slide show. I'm not going to click all the way through that thing.

Either put it all on one or two pages (interspersed with ads if you must), or put it into a slide show if the article is written as a slide show.

Re:This is not a good approach

[Gnavpot]

Tell me how to get Monsters Inc. Scream Team Training to run on a non-admin account without me manually entering an admin pw into Run As... every time and I'll be unbelievably grateful.

If you are on XP Pro (not XP Home), you should look into the '/savecred' option for the command line version of RunAs.

First time a program is started with 'runas /savecred /user:administrator', you will be prompted for the administrator password. The next time this command is used to start the program, XP will remember that this user is allowed to run the program with administrator priviledges and will not ask for a password. To make things a little more convenient and self-explanatory, you can put the command into a .bat file, make a shortcut to the .bat file and select the program's icon for the shortcut.

It is certainly not a perfect solution, but it can solve some problems.

However, you should not use this solution if you don't trust the user. I am almost certain that the program can be replaced with another program with the same name without revoking the priviledges.

Re:This is not a good approach

[laplandsix]

Right click the shortcut and prepend the following:

C:\WINDOWS\system32\runas.exe /savecred /user:administrator
The first time you run the app it'll prompt you for the admin password (in an UGLY ass dos box) after that it'll run with no prompting. Honestly, this isn't rocket science. Not quite as slick as suid, but it works. Until you change the admin password of course.

Problem/Issue is obvious if you understand Unix

[fortinbras47]

Windows is continuing its transition to the Unix user/security model, but your average user (and many IT people) neither understand the user/admin distinction nor permissions.

As I understand the article, EVERYONE in Vista is a normal user. Administrators have the ability though to take administrator actions on a case by case basis after supplying credentials.

To me, this sounds exactly like "sudo" under unix/linux or the "Authenticate: blahblah requires that you type your password" under Mac OS X. This model is more secure and works great, but there are some legacy transition issues.

For you unix people, the problem the article describes is, "what if you mount an old drive, the drive has restrictive permissions, and the file owner UIDs don't match the new system?" (your user account doesn't have permission to do anything on the drive)

NTFS has file permissions, but they rarely came up in practice because everyone in Windows was doing everything as the Unix equivalent of root. In Unix, the obvious fix is to do a sudo chown -R newuser /mnt/olddrive (or an ultraghetto sudo chmod -R o+rwx /mnt/olddrive) . The user/permission concept is totally foreign to your average windows user though, and hence the problem.