Running As Normal User


As most of you probably know, Microsoft is a land of acronyms. We mostly prefer the 3-letter variety here (TLAs), but I’ve been spending a lot of time lately thinking about one of the 4-letter ones: RANU. RunAs Normal User.

Just to be clear about what I mean, I’m talking about one of the hurdles we set and will clear for Visual Studio – the Visual Studio environment must be able to run when the logged-on user has only* Normal User privileges (that is, does not belong to the Administrator or Power User groups). I put an asterisk there because I’m sure there will be various exceptions to the rule, but that’s generally a pretty rigid criteria.

Note that this applies to the Team System client features as much as the rest of Visual Studio, which is why I’ve been thinking about it a lot lately. Being able to run as Normal User is an important layer of defense when it comes to using your computer securely — that’s a big part of where the requirement comes from. The fact that many corporate LAN users aren’t admins on their machines is a concrete demonstration of both the value of the defense and the need for our software to play well with it.

Yet, as has been said elsewhere, FAR too many people out there are admins on their machines. Even I’m guilty of it. There are various reasons, even a few reasonably-valid ones. This sort of strays into the territory of where if the user can’t do something painlessly, it’s just not good enough yet. In some ways it doesn’t matter if a feature is there, if it’s well-documented, if it’s A Best Practice, etc. — if it doesn’t just work, then it isn’t done yet.

Windows is, as a product of its own history (IMHO), at this point as far as the default user being an Administrator is concerned. There *are* now various facilities there that make it very *possible* to run as a normal user by default, and temporarily elevate to Admin privileges when necessary, in a controlled fashion. But it’s by no means painless/discoverable/easy — however you want to characterize it. That’s part of the problem. The other problem, of course, is that too much software out there – some MS software to be sure, but boatloads of 3rd-party software as well – either take for granted that the running user is an Admin, or (essentially) require the user to be, sometimes with spectacular results if they’re not.

For example: Practically every PC game out there – *still* – seems to expect the running (not just installing) user to be admin. They want to write/modify some set of files that live in their install folder – %systemdrive%\program files by default. Well, as some of you know and others may not, Joe Normal User can’t modify or create files anywhere under Program Files (by default). There are a few games out there that store configuration/save data in better places, such as under Documents and Settings\<current user> somewhere, but they still seem to be the exception rather than the rule.

As long as it’s hard to run as normal user – either because the OS doesn’t help you deal with it, or because lots of software expects it, or both – it will be hard to convince many users out there to “play it safe”, because it’s too much work and you may never see a return on your extra effort (after all, it is a layer of defense, hardly the only aspect of safe computing). But, it’s something I’m going to start pushing myself to do, and I figure it’s a good thing to start encouraging others to do as well.

Now, on to the good news and a group “challenge”. I said it’s still not easy to “RANU”, but I want to see just how easy I can make it, with your help. I started to write up some features and tips/tricks I’ve picked up over time about how to deal with this, but I just got pointed at Peter Torr’s thoughts on the subject, and he did a great job of covering what I know about the subject and then some. So, take a look at his post and feel free to post your own thoughts, any additional tips or tricks you know about, and so on. It will ultimately fall to the Windows team to really make this layer of defense as painless as possible, but that doesn’t mean there’s nothing we can do in the meantime.

Comments (4)

  1. I just finished writing an update program that I knew would be run exclusively by members of the "Power Users" group, so programming with diminished priveleges was very important during the development. I’d actually prefer to do everything this way, but the one sticking point I’ve had is that I can’t debug without at least being a member of "Debuggers". I know that I shouldn’t need to step though my program if I want to qualify as a hairy-chested he-nerd. I should be able to just look at my code and know the state of everything at any time. But I’m just not that good yet. I’m still haunted by my memories of my Alma Mater’s computer lab… eleven hours to re-create an OpenGL program from memory as a result of a hard drive crash… I sit down with full confidence that I could do it, only to find that I can’t step through my code, because I’m RANU. What would have taken me till 5pm took me until 11:56:00pm (it was due at midnight) because I had to debug everything with the artful use of afxmessagebox-es. So RANU is very scary for me. What I did on this last project was to look closely at my specs, and figure out what might cause problems when RANU on the specific platform I was writing for(accessing the network, writing to the registry, running install packages, adding, replacing and deleting files), and taking these limitations into account. I didn’t want the program to crash or fail ungracefully if it tried to do something without the right security level. Although I programmed as an Administrator, I would test the program as the target user (Power User) at key points in the development cycle. It was a little bit easy for me, in that I knew the program would always be run as a "Power User," but the whole process showed me how important it was to take user privelege levels into account while programming and testing.

  2. Oh god, I’m SO damn glad someone at Microsoft is aware of this.

    I know this might be considered unsporting, but why don’t you look at what Apple does to let their "admin" on OS X run as a normal user *except* when they need to temporarily boost privileges for some purpose? Something like that would let people wean themselves off running as Admin, *plus* make it achingly obvious when some idiot program is expecting a Windows-95 environment…

  3. Chris says:

    Will,

    Personally, I don’t see using a debugger to … *Gasp* debug… as a weakness. It’s a POWERFUL tool and can greatly reduce the time it takes to diagnose and fix problems in code. Yes, you CAN work around it (with whatever equivalent of "print reached foo.bar()" is available), but not having to stoop to that level of effort is what the debugger is all about. Yes, having to be in the debugger group is a pain, but a pretty small price to pay compared to being in Administrators.

    It’s also gratifying to see developers that put themselves in their users’ shoes in various ways – as you said, failing gracefully if necessary permissions or resources aren’t available (for RANU reasons or whatever else). You’re right to observe that even if you require Admin privilege to run (something to avoid!), you should test as Power and Normal users to ensure that you fail gracefully and report the problem in a way the user can handle.

    "JazzNupe",

    Nice post, I’ll definitely follow-up on Aaron’s site myself. I’m typically using a domain account here at work, so I suspect I won’t be able to use the toolbar, but either way, good stuff. I’m a normal user at home, after all..

    Peter,

    The good news is that I’m hardly the only one thinking about RANU – as I alluded to, it’s a hard-and-fast requirement that VS run as a normal user, and has been for some time (*debugging* however, as Will pointed out, generally requires that specific additional permission). As far as Apple goes, my $0.02 is that if you can’t talk about the competition rationally, you’re headed for trouble. So I wouldn’t consider talking about Apple in general, and their OS in particular, to be "unsporting" at all. After all, most of the people here LOVE lots of what Apple does. Several people have iPods. The first time I saw that Cinema Display of theirs, I was sorely tempted by the Fruity Side, let me tell you. I’m still scratching my head over the one-button/no-button thing they keep doing, but I have to remember that I Am Not Necessarily My Target User, or theirs, for that matter.

    As for how they go about ‘limited admin’, can you elaborate on what they do? I don’t have a Mac handy to see for myself. I’ll make it a point to play around with my father’s G4 next time I visit him, though…

    I should also note that there ARE ways to fool obstinate programs into behaving; there’s a tool internally here that can (apparently; I haven’t tried it) "shim" its calls into Program Files (and other restricted areas) to wind up in territory accessible to a normal user. If we can make things like that part of the AppCompat system, we’ll be getting somewhere!