It's been a while since I wrote anything, but I came across a little gem. Michael Stiefel wrote an article about Code Access Security, or CAS. At the end of the article, he states "Friends don't let friends program as administrator." Why is that, you may ask? Well, here is a scenario. I work with a network containing thousands of users. They're all managed with a domain. Now, of course, we don't want to give administrative rights to every single user. We limit the administrators to 1-5 per unit. These administrators have two accounts. They have a user account (for using the internet) and an administrative account. For security reasons, the administrative account is blocked from all HTTP, FTP, etc.
Over the months that I've been here, I've become a remote administration buff. I hate getting out of my chair. Previously, when I was back in the states, I was logged in as an account that had administrative access to my entire unit. Now, I am forced to be on a non-administrator account, and use the "Run As..." function to perform tasks. Works all fine and great - until you run into something that you can't use "Run As..." for.
The point is that you cannot guarentee that a user will have the same rights as you do when you create the program. Jeff Atwood, in The Programmer's Bill of Rights, states that all programmers should have a fast PC, for development. However, the comments below state that programmers should not only have a fast PC, but a median PC, something equivalent to what average users would have.
A good programmer wears two hats. The first hat, is the developer. The developer writes the code, makes the magic happen. However, every developer must know their roots. Every developer started off as a user. Developers have a job because of one thing - the user. If a program doesn't have a single user - it doesn't need to exist.
That said, every programmer needs to swap between these two hats. They develop in the developer's hat... Then all testing should be done in the user hat. This ensures that you, as the developer, experience every single issue that the user would experience, including lack of administrative rights.
You cannot assume that a user has any administrative rights. When you do need administrative rights for your program, you should use CAS. CAS will let the administrators know what rights you need.
Friends don't let friends program as administrator.
Sunday, August 26, 2007
Friends don't let friends program as administrator
Subscribe to:
Post Comments (Atom)
3 comments:
I've seen articles involving purposely reducing the rights your software has, regardless of whether they run it as administrator. I haven't done much about it, but that way, any security issues you may have later on can't be exploited as much as if they had administrator rights.
I'm sure this would also help in ensuring administrators and users get the same ride though.
I think I'm going to start a series of articles on CAS. Don't know if I'll get to it today, but I'll try to do an article every day ... /try/
Considering every end-user installable commercial piece of software has minimum and recommended ratings, it seems like all developers or at the minimum, qa or documentation, should automatically be firing up the app in a minimum-rating or recommended-rating virtual machine rather than on the real hardware.
Of course, qa and dev are about getting the product out the door, and customers and support are the ones who have to deal with poor performance or complaints. If customer support's management was looking out for themselves, they'd be firing up the QA builds and logging bugs before the product launched. At least that way when a customer had the same complaint, support would know there was a bug already filed on it and could close the call faster.
Post a Comment