When I first saw these, I felt comforted. I was used to seeing the same on my Mac OS X boxes when an application was requesting admin or root privileges. However, the sheer number of times that I needed to actually acquire administrative access to my machine surprised me. I would often think, “Does this thing really need administrative privileges to work?” In a lot of cases, the answer was, “Yes,” but in some, it seems that some more work could be done to either allow an application to install/run with user privileges (e.g., browser plugins) or to isolate preference options according to whether they need the dreaded “elevation”2. Ultimately, though, that work can be done, and application developers and IT folks have some Microsoft-provided tools that can help them make their applications/plugins/whatever behave well in this environment.
Later, I would increase my Good Dogfooder™ karma (or reduce it, depending on whether you subscribe to the only-negative-karma idea) by enrolling in a pilot program to try out redirecting user folders to a network share. It pretty much works as advertised. Everything that would be in
C:\Users\nathanh.000 gets redirected to a network volume that my domain account has read/write access to. It takes a bit of time to log in, but no matter where I log in, I have the same information. Similarly, there a few applications and products that don’t handle this gracefully... applications that like to install shortcuts on the Desktop, for instance, are annoying unless they’re installed somewhere on my user directory (which is rarely, if ever) or installed in the same location on every machine I log in to. Again, I can report back my woes and, at least with Microsoft-written applications, have a shot at having them work better in that environment.Alas, as is usually the case with living on the bleeding edge, there’s the blood. Dogfooding at Microsoft is de rigeur, and there will always be some annoyances, though the product teams do a lot to keep them to a minimum. My problem is the confluence of elevation in the presence of the network home folder.
Let’s review: My domain account is my main account, and is a standard user, not an administrator. My administrative account is a local machine account, and has no domain privileges at all. My home directory is a mounted network drive where my domain account has privileges, but not my local machine administrative account. Do you see what’s coming?
Situation #1: Installing from a network share.
I can browse to some UNC path from my domain account, and click on an installer. The installer, UAC-aware as it is, puts up the elevation dialog, since it has to install into some machine-wide areas. I enter in my local administrator account and password. Voilà, the installer now runs as if it is the local administrator account, and instantly no longer has access to the network share, since my local administrator account doesn’t have privileges. Fortunately, this is usually only an annoyance, as most of the time, I am presented with a dialog complaining that the installer doesn’t have access to the share, and could I please enter in credentials of someone who does. I find it odd that I have to enter in my own credentials when I’m already logged in as myself.
Situation #2: Installing into the home directory
In the case where an installer needs to install into some machine-wide area as well as the home directory, I’m more stuck. I have to elevate to run the installer, but as soon as I do that, the installer loses access to the home directory. For some reason, in that case, it doesn’t present the network-access dialog, and things just fail to work.
In one such case, a program installed most of its items, but then failed to create a startup shortcut for me. “No matter,” I thought, “I’ll just copy it over myself.” I noticed that the shortcut I needed was already in my Start menu, so I browsed to it and copied it. I then browsed to the All Users startup items folder and tried to paste it as a shortcut. I then get the following dialog:
Windows cannot create a shortcut here. Do you want a shortcut to be placed on the Desktop instead? [Yes] [No]
“Hunh,” I think, and choose, “Yes.” Personally, I thought it should have just brought up an elevation dialog and let me paste the shortcut, but no matter. There is more than one way to do it. So, I then try to drag the shortcut nicely pasted onto the Desktop to the All Users Startup Items folder. Happily, I get the elevation notice. I think, “Great! Now I’ll have access to put this item here.” But I had not thought it through, for while I gained access to put the shortcut there, I simultaneously lost access to its source. Thus, after another elevation dialog (I don’t think that one should be necessary), I get the following dialog:
You don't have permission to copy files to this location over the network. You can copy files to the Documents folder and then move them to this location.
I take issue with this dialog on two accounts. (1) I have permission to copy files to this location; I just got it. I just lost permission to copy files from the source location. “to” is a little unclear. (2) Copying files to the Documents folder is not going to help me, since my Documents folder is also on the network share location that my Desktop is.
The sad part is I could have elevated, and copied the shortcut directly, without ever having to place a copy on my network home directory. But I wasn’t thinking through the ramifications.
Unfortunately, neither will our users. Furthermore, they’re not going to understand why these things don’t work “right” or “just work.”
I am not part of the UAC team and have definitely not considered all the ramifications of the implementation of extreme credential isolation, but I am certainly enjoying the authorization mechanism on Mac OS X which allows me as my current user (with all the access that implies) to do specific other tasks requiring a higher authorization level by supplying administrative credentials, and still have access to the secured resources my user should have access to.
I expect the UAC edges will get smoothed out, as will network home folder redirection... I mean, hey, why else do we do this dogfooding anyway?
--
1Actually, it was at that point that all Microsoft employees were exhorted to all use Vista as our desktops–even though no official effort had been made to ensure that our group’s build environment and tools would still work–so that we would make sure the experience would be good for our customers. Our woes were noted, and some were addressed in time for Vista and associated tools to be released to manufacturing, so our pain was not in vain.
2Originally, I thought “elevation” was just a synonym for authorization. Alas, it is not. When you “elevate,” you (or rather your process) becomes owned by another user with more privileges than you. That user may also have fewer privileges than you in other realms. This can be a problem.
2 comments:
In reference to your second footnote, when is a user with a full administrator access token going to have fewer privileges than a standard user account?? I don't even think that's possible; is it?
That was the whole point of the problem I lay out. The local administrator account has full control of the box but no control over the remote share, which is limited to domain-accounts only. When you become the local administrator, you immediately lose your rights on those remote volumes.
Post a Comment