A fresh look at Vista's User Account Control, Part 2

A fresh look at Vista's User Account Control, Part 2

Summary: User Account Control is a controversial new feature in Windows Vista. 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. Why do these prompts appear? And why do some so-called Windows experts miss the obvious reason (and the obvious fix)?

TOPICS: Windows

[Update May 5, 2006 1:35pm PDTA portion of this post was accidentally deleted on May 4 due to a production error. The text has now been restored and can be seen here. – Ed Bott.]

In the first post in this series, I provided a close-up look at a major new security feature in Windows Vista. User Account Control (UAC), which will be enabled by default in all versions of Windows Vista, monitors a user’s actions and prompts for an administrator’s credentials before allowing any action that has a potential impact on system security.

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

File operations trigger a UAC prompt anytime you try to do something with a file or folder where your current set of user rights doesn’t grant that access. For example:

Next >>

Topic: Windows

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • The only real solution

    Microsoft can impliment a million automated wizards and workarounds that help the average user limp through the pain of least priviledge, but the only real solution is for Windows application developers to start writing their applications properly.

    There is hope. I've noticed that lately, it seems a much larger percentage of new Windows software follows the rules out of the box and works for limited users. Both Macromedia Adobes entire suites seem to be compliant, and even WinAMP 5, a long time offender has recently changed their program to keep settings in the users profile.

    Nice blog by the way. Paul Thurrott should read it. He might learn a few things.
    • Amen!

      We have some vendor supplied software that requires admin rights to install. WTF! Why does air handler selection software need admin rights to install? IMHO, most of the problem is that they did it the "quick and easy" way.
      Patrick Jones
      • Requiring admin rights to install isn't my gripe

        IMO, requiring admin rights to install isn't necccessarily that bad. It's when they require them to *run* that drives me insane.

        But yes, apps *can* be written to install on a per-user basis.
        • Some are like that, too

          It really chaps my ass :) If only I controlled our specs, I would have those vendors removed until they fixed their crappy software.

          IMHO, as long as the software doesn't mess with the system (which would include IE, and WMP since they are "integrated") it shouldn't need admin rights to install or run. But that is just me :)
          Patrick Jones
    • Memory lane.....

      I remember we did this in the mid-80'es on IBM S/36 and S/38.

      To shortcut any security measures made by the administrator, you made the program run with adopted rights. The user you adopted was secoff, which is the same as windows administrator or unix/linux root. It assured that the program would run.....

      I my world the user should be allowed to install programs granted by the administrator, including whether they should be installed as 'allusers' or the specific user. This gives the admin contol of the PC's.

      Naturally this control is much easier to maintain if you skip the PC, and use a Citrix-based thinclint solution. This set-up will work for 95% of business users.

  • So what's the problem?

    First you start off using examples of mucking about in the "System" folder. Then you end up with an example of the "My Pictures" folder.

    1. A typical user shouldn't be messing about in the "System" folder anymore than a typical user shouldn't be messing around in '/sbin".

    2. A typical user should own "My Pictures" just as a typical user owns the "/home/jsixpack" directory.

    In all cases the "Admin/root" accounts control the sensitive stuff and "jsixpack" controls the access to their stuff.

    All you really seem to be saying is that the Windows folks (users and applications providers) need to catch up with the rest of the world (i.e DG AOS/VS, DEC VMS, and the myriad of *NX OS's as a sample).
    • Read more carefully, Bill

      I was showing a comprehensive picture of where file op permssion dialogs appear.

      The "My Pictures" folder I showed was on an external USB drive and had been created with Windows XP. When accessed from XP, the user has full rights to this location. But Windows Vista has no way of knowing that this user should have rights to these files.

      Lots and lots of people have external drives now. This will be a real issue. Again, go back and read more carefully instead of jumping to conclusions.
      Ed Bott
      • Rights to external drives..

        So you basically have to give everyone full rights to your external drive?

        How was this user setup? Was it a user on domain machines? Two separate non-domain machines with just the same user name?

        If it was the domain machines, then Microsoft needs to work this out. If it was two non-domain machines, then they are technically two different users and would not have the same rights. Granted, that is a PIA but it does mean that the security is working like it should. Although, most people just give everyone full control and go on about their merry way.
        Patrick Jones
        • How it works

          On a newly formatted NTFS drive, Windows XP gives default set of permissions.

          It's something like this:

          BUILTIN\Users - Read Only
          BUILTIN\Administrators - Full Control
          BUILTIN\System - Full Control

          Each of these "builtin" groups is represented by a SID (Secureity Indentifier). The SIDs for the "BUILTIN" class of users are [b]indentical[/b] on all Windows systems, weather they are domain members or not. Because of this, when one Windows systems sees a drive from another Windows system, it will recognize the "BUILTIN\xxxx" groups, and can enforce the appropriate permissions on them.

          If specific rights are granted to a user on that drive to a non-default user, like myoldmachine\joe, the new XP/Vista machine will not be able to resolve the SID and therefore, not be able to enforce those permissions.

          On Win2k, the default permissions for a new drive was "BUILTIN\Everyone - Full Control", which was certainly convenient, but not terribly secure.
          • Most external devices are formatted in FAT

            So Ed does have a point
          • Not really...

            Most removable devices like flash drives are formatted with FAT, but I don't know that external drives are FAT-formatted. It would be pretty inefficient.

            Anyway, a FAT-formatted drive has no security restrictions whatsoever. ACLs are only appplied to NTFS volumes.
            Ed Bott
      • message somewhat vague ...

        I was also confused somewhat by the examples article. For the majority of the examples presented, it was NOT obvious that you were accessing an external drive. The multi-paged article may have contributed to this disconnect, and you may want to reconsider it in future posts (IMO).

        Additionally, I agree with Cardinal_Bill that the access permissions on file systems must be locked-down from general access. In a world of increasing bandwidth and ubiquitous "always-on" internet connections, security must NOT be sacrificed at the expense of user convenience. This, of course, requires cooperation between OS and software developers and the users of the software products -- in other words MS is not solely responsible for any existing lack of security in the Windows environment.
        David A. Pimentel
        • My mistake

          The original version of this post was a single page that contained a lot of graphics and needed to be broken. I worked with a ZDNet editor to convert it to a more manageable format. I agree we could have done a much better job and that the final result is not easy to read. Feedback heard loud and clear.

          Also, in the editing process a large chunk of text was inadvertently dropped, and it had a major impact on the meaning of the post. I'll provide a link to the missing material as soon as I get it posted.
          Ed Bott
          • See the updated page


            Ed Bott
          • Thank you ...

            ... that helped to clarify the information. One definitely needs to keep those editors inline ;-).
            David A. Pimentel
    • The problem is *not* the users

      It's the application developers that continue to write their programs without regards to security, and of course, Microsoft's fault for bowing down to the God of backward compatibility when it released Windows XP. The users are simply caught in the wake and don't know how to get out.

      For example, some programmers still store their program's settings in an .ini file under the windows directory. Running a program like this will prompt one of these warnings in Vista everytime the user runs the program and it tries to modify it's settings file. In Windows XP, the user will get a big fat access denied error, or in some cases, the program will just crash.

      The most common mistake I've seen is either keeping program settings in the program folder itself, or keeping them in the HKEY_LOCAL_MACHINE\SOFTWARE part of the registry.

      Application developers will shout, "but I want program settings to be global". We'll there is a solution for this. You put the settings in the "all users" profile under documents and settings and set ACL's on them that allow all users to modify them when you install, you can also place them in the HKEY_LOCAL_MACHINE\SOFTWARE and set appropriate permissions too if you really want to.

      The rules to follow when writing a Windows app are no more complicated than those in UNIX.

      * Keep program files in the "program files" folder

      * Keep program settings in "documents and settings\username" folder

      * Keep global program settings in "documents and settings\all users" folder

      * Keep global registry settings under "HKEY_LOCAL_MACHINE\SOFTWARE\xxx"

      * Keep user specific registry settings in "HKEY_CURRENT_USER\SOFTWARE\xxx".

      From my experience, most "Joe Sixpack" users who are ignorant of security are content to save all of their files in the "My xxxxxx" folder, simply because on just about any app, it's the default save location. The problems start when applications start breaking the rules. When this happens, user are the victims, not the problem.

      Now, the group of users who seem to cause the most problems for themselves and raise the most fuss with Vista's new UAC system are the so called "power users". These are the type of users who know what the registry is and how to get into it, understand the basic layout of the Windows filesystem, and know where every little control panel is and like to play with every little function in them. These are the types who know "just enough to be dangerous". Though their knowledge of Windows is much higher than that of the average user, it's still largely supeficial, and when they innvitably start mucking around in the "\program files" or "\Windows\system" directory and run into errors, they get mad when Windows smacks them down. The sad part is, [b]many Windows IT "proffessionals" fit this profile[/b]. :(

      I don't envy Microsoft one bit. They are trying to get out their hole in regards to least priviledge, but they've dug it pretty deep.
      • I agree for the most part

        "For example, some programmers still store their program's settings in an .ini file under the windows directory."

        And for a good reason - the windows "registry" is a step backwards, and it's all messed up. Not to mention it's very unfriendly for beginning programmers. Messing around with the wrong keys can really mess things up.

        Other than that, I agree for the most part.
        • Use whatever you want - just use it properly

          Well the registry has its strengths. It's hierarchical, enforces some semblance of consistency, is transaction based (pretty reliable when store on an NTFS file system) and is at least separated into several separate hives and can be restored relatively easily in the case of corruption. But yeah, the "all the eggs in one basket" part of the registry sucks, cause a bad stick of RAM or bad HD sector can bring the entire thing down.

          I've read somewhere that in .NET, the preferred method of storing configuration is now an xml file, so perhaps Microsoft is stepping away from the registry.

          My point was not that using text files is wrong. If developers want to use text files, fine. Just put them in the documents and settings folder [i]where they belong[/i].
          • Exactly

            Firefox does this very well. All configuration files are in the logged-on user's profile in Local Settings\Application Data. It's even more rational in Vista, where there's an environment variable that can take you straight to personal storage for application data: %localappdata%.
            Ed Bott
      • Users want backward compatibility.

        Why spend extra money for something better?

        MS has capitalized on that rather nicely.