Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Running Non Admin

Running Non Admin

  • Comments 38

There’s been a fascinating process going on over here behind the curtains.  With the advent of XP SP2, more and more people are running as non administrative users.  Well, it’s my turn to practice what I preach, I’ve taken the plunge on my laptop and my home machine, I’m now running as a non admin user (I can’t do it on my development machine at work for the next few weeks for a variety of reasons).

The process so far has been remarkably pain free, but there have been some “interesting” idiosyncrasies.  First off, I’ve been quite surprised at the number of games that have worked flawlessly.  I was expecting to have major issues, but none so far, with the exception of Asheron’s Call.  Annoyingly, the problem with AC isn’t the game itself, it’s with Microsoft’s Gaming Zone software, which insists on modifying files in the C:\Program Files directory. 

Aaron Margosis’ blog posts about running as a limited user have been extremely helpful as well.

Having said that, there are some oddities I’ve noticed.  First off: There seem to be a lot of applications that “assume” that they know what the user’s going to do.  For instance, if you double click on the time in the system tray, it pops up with “You don’t have the proper privilege level to change the System Time”.  This is a completely accurate statement, since modifying the time requires the SeSystemTime privilege, which isn’t granted to limited users.  But it assumes that the reason that I was clicking on the time was to change the time.  But maybe I wanted to use the date&time control panel as a shortcut to the calendar?  I know of a bunch of users that call action of double clicking on the time in the taskbar as invoking the “cool windows calendar”, they don’t realize that they’re just bringing up the standard date&time applet.  If I don’t have the SeSystemTime privilege, then why not just grey out the “OK” button?  Let me navigate the control but just prevent me from changing things.

Similarly, the users control panel applet prompts you with a request to enter your credentials.  Why?  There are lots of things a limited user can do with the users control panel applet (enumerating groups, enumerating users, enumerating group membership, setting user information).  But the control panel applet ASSUMES that the user wants to manipulate the state of the other users.  It’s certainly true that most of the useful functionality of that control panel applet requires admin access.  But it should have waited until the user attempted to perform an action that was denied before it prompted the user for admin credentials.

From my standpoint, these examples violate two of the principals of designing interfaces that involve security: 

1)      Don’t tell the user they can’t do something until you’ve proven that they can’t do it.

2)      Don’t assume what access rights the user needs to perform an operation. 

The date&time control panel violates the first principal.  The user might be interacting with the control panel for reasons other than changing the time.  It turns out that the reason for this is that the date&time applet violates the principle of least privilege by enabling the SeDateTime privilege, running the control panel applet, and then disabling the privilege.  If the control panel applet had waited until the user clicked on the “Apply” button before it enabled the privilege (and then failed when the enable privilege failed), it would have better served the user IMHO.

The users control panel applet violates the second principal.  In the case of the users control panel, it assumed that I was going to do something that required admin access.   This may in fact be a reasonable assumption given the work that the users control panel applet does (its primary task is to manage local group membership).  But the applet assumes up front that the user has to be an administrator to perform the action.  There may in fact be other classes of users that can access the information in the users control panel – as an example, members of the domains’ “account operators” group may very well be able to perform some or all the actions that the users control panel applet performs.  But the control panel applet doesn’t check for that – it assumes that the user has to be a member of the local administrators group to use the control panel applet.  Interestingly enough, this behavior only happens on XP PRO when joined to a domain.  If you’re not joined to a domain, the users control panel applet allows you to change your user information without prompting you – even as a limited user.   Peter Torr also pointed out that the computer management MCC snapin (compmgmt.msc) does the “right” thing – you can interact with the UI, perform actions (adding users to groups, etc), and it’s only when you click the “Apply” button that it fails.  The snap-in doesn’t know what’s allowed or not, it just tries the operation, and reports the failure to the user.

This is a really tough problem to solve from a UI perspective – you want to allow the user to do their work, but it’s also highly desirable that you not elevate the privilege of the user beyond the minimum that’s required for them to do their job.  The good news is that with more and more developers (both at Microsoft and outside Microsoft) running as non administrative users, more and more of these quirks in the system will be fixed.


Edit: Thanks Mike :)
  • Rob,
    I actually wrote the post close to a month ago, and had been running as a non admin for about a month before that.

    Having said that, yeah, I should have been a non admin before that, mea culpa :)
  • The hibernate versus shutdown thing isn't that odd. When you come out of a hibernate, the desktop is always locked. So the only thing hibernate can do is prevent an already started program from continuing to run.

    But consider: if you can touch the hibernate button, then you have physical access to the machine. So you could cut the power to it anyway and achieve the same thing.
  • Quote:
    But maybe I wanted to use the date&time control panel as a shortcut to the calendar? I know of a bunch of users that call action of double clicking on the time in the taskbar as invoking the “cool windows calendar”

    YES! Finally someone in MS has acknowledged the most annoying part of running as a limited user. My solution? Desktop Sidebar. It has a calendar and a clock I can simply look at. Oooh pretty.

    The biggest hotkey I know for limited users? Left shift. This is extremely useful in the control panel when right clicking on things like Add/Remove programs. It's the only way to bring up the Run As... shortcut on some contextmenus

    I also keep a shortcut to "runas iexplore -new C:" (removed full path for shortness). This allows me to run Explorer as Administrator so that I can change certain things like Security permissions for those weird games and other applications not programmed with the thought of multiple users in mind (circa '95). For those I simply give the Users group Write and Modify permissions of the directory only. Problem solved. I know it's kind of a security risk but the applications I have to change are almost useless to begin with.

    The only way to fix it completely is for developers to write software with multiple users in mind. Even if the intent is for only one user on the system to use it, you can still get away from designing software using this approach. I have some applications that I NEVER have to tweak in this way: RSSBandit is one, SharpDevelop is another. If I don't have to touch security settings for your application I consider it a good thing.

    The sad truth is I bet we'll see a lot of Longhorn apps still being coded in this pre-2000 "one user, one system" mentality. Even if the system itself will exhibit a limited priveledge mentality, the applications that run on it will lag far behind.

    I think we need a list of "non-admin friendly" applications. That way some of us can point and laugh at those developers who insist on developing applications in a Windows 95 mentality. That would also allow those of us running as a non-admin to pick only those applications that will cater to our needs. I normally try to find cheap software but there have been times when I would pay dearly for something that'll work naturally in the environment I've learned to embrace whole-heartedly. I don't login as root on my Linux boxes any more, so I'm not about to run as Administrator.
  • To digress (only slightly) from Larry's excellent post, and respond to Jeremy's "one user - one system"... I recall trying to figure out how to make a nameless media player work on my Uncle's PC with different profiles. For good reason, my uncle didn't want to share a playlist with his son - but that wasn't possible.

    To get more on point with Larry's post and comments, make sure when testing software during development to have an XP Pro machine with NTFS to catch issues related to non-admin filesystem permissions.
  • Everyone's Talking About Least Privilege!
  • Another convenient thing to have would be a "copy as" or "delete as" command. For some reason, I can't run Windows explorer as a different user, and this makes it more difficult to install programs that don't have setups.
  • Another convenient thing to have would be a "copy as" or "delete as" command. For some reason, I can't run Windows explorer as a different user, and this makes it more difficult to install programs that don't have setups.
  • Also, why do I have to be an admin to change my file associations? What if two users of the same computer want to use different web browsers or image editors?
  • Larry,

    > I don't test as a limited user

    Isn't testing the whole purpose of developing as non-admin ? OK? I understand that in your specific case, you may need to run as admin to debug. But then, what's the point to bother developing as non-admin ? (I mean from development task point of view, not from a generic computer usage point of view).

    > unless there's a specific test case that fails when running as a limited user.

    You assume that you know upfront what these cases are. My understanding is that developing as non-admin is useful precisely to minimize the probability that we forget such cases.

    Or did I miss something ?
  • I run as a user. I had been running as an admin for a long while, then I switched to running as a user, then switched back to running as an admin because I need to be able to debug web applications, Windows services, I need to be able to install/uninstall things (e.g. message queues) as pre/post build steps, I need to use Server Explorer and so on.

    I'm experimenting a different approach now: I run as a user, but I run Visual Studio as an admin, with the user's environment ("runas /noprofile /env /savecred /user:Administrator devenv.exe") whenever I need to do "advanced" stuff. For "regular" stuff (e.g. Windows Forms), VS works ok even as a user. Still investigating what the pros and cons could be (I had a bit of trouble with extension packages in VS, but otherwise thing seem ok so far).
  • Serge,
    No, testing ISN'T the point of developing as non-admin. Developing as non-admin is about ensuring that my machine isn't vulnerable to security holes.

    When I'm testing, I'm testing a new functionality I'm adding to the system. For that, I need to be able to attach a debugger to random processes, modify the registry, install new COM components, update service config, etc. In other words, I need to be an admin.

    Now, you could say that I'm testing Windows XP when I'm running XP as a non admin, and that's a fair comment. But any testing I'm doing in that configuration is incidental to my development work, and isn't my primary focus.
  • "Isn't testing the whole purpose of developing as non-admin?"

    Remember, Larry is lucky enough that the REAL testing of his work is done by someone else. The last time I did any development in a team with dedicated testers, my testing was of the "it compiles, runs, doesn't break the build, and seems to do what I intended it to". I then handed it over to someone else who hammered it to death in completely unexpected ways and handed it back to me...
  • 9/22/2004 10:51 AM Larry Osterman

    > To debug a running process, you need the
    > SeDebug privilege. And that means that
    > you're effectively an admin.

    From the point of view of security threats you're effectively an admin, but from the point of view of reducing the damage from accidental human errors you're effectively not an admin. Try taking advantage of it.

    > Instead of being a true admin, you could go
    > with Power User, but it's trivial for a
    > power user to elevate their privilege to
    > admin.

    Exactly the way it should be. When you need a privilege and decide you want to use it, you take it. There are still two conflicting goals here, so let's consider some options.

    With programs, the principle of least privilege is exactly correct. When a program needs a privilege, take the minimum privilege needed, and then revoke that privilege as soon as possible. This takes some extra effort in development but it goes far towards reducing both the damage caused by accidental errors (bugs in programming) and malicious security threats.

    With human operations, picking one minimum privilege and guessing wrong (actually needing a different privilege, or an additional one or six of them) is irritating and frustrating. So if a human operator can take extra care while operating as administrator, maybe it is safe enough to temporarily take all privileges and then revoke them as quickly as possible. But I still prefer the VMS philosophy rather than the Unix philosophy on this matter. With Unix you're forced to temporarily take all privileges. With VMS you can choose for yourself whether to temporarily take all or temporarily take minimal (or temporarily take some other subset).
Page 2 of 3 (38 items) 123