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 :)
  • There's a fine line between two different annoyances. It's damned annoying to not be able to open up an applet you know has nothing worth securing visibility of, only changes. But it's possibly more annoying to open up an applet, futz around, think 'this is good', hit OK and get a big 'NO AUTHORIZATION' blaring. You just wasted all that time and mental energy and have to log in elsewise and redo it. The power options applet is a perfect example of this - a limited user can't even view the current settings if I remember correctly; a few times I've tried setting them all as I need them only to be kicked out and log in as admin to find them already there fine.

    The best is the advanced network connection sheet's method, just disable options that aren't allowed, except that the deisgner has to be conscientious enough to check for privelidge for each option, and do it right. Ah, the pitfalls of UI design.
  • I feel that running non admin works well when using XP Pro but on XP home it causes more pain as most of the rights are already preset.

    For example try to hibernate without being an admin (not easy as you can't give the right, and strangely enough it was still working ok under SP1 but not anymore under SP2 :-( ).

    I still prefer to be non-admin but I suspect a lot of home users will not accept this.
  • This Windows vulnerability shows that even the simplest programs can have issues. It is also a strong argument for not running Windows with Administrative permissions....
  • En Windows tenemos el síndrome de ejecutar las aplicaciones como Administrator. ¿Podremos quitarnos ese vicio?
  • OK, the last entry was a teaser for a blog entry or two on what developers can and IMHO should do regarding...
  • PingBack from

Page 3 of 3 (38 items) 123