Forgot your password?
typodupeerror
User Journal

Journal: Coding for Security, or "Testing Is Hard."

Journal by gfecyk
I read this a couple of days ago. The article it references suggests that IT administrators are petty dictators who don't let developers get their job done. or at least that's the impression I came away with.

Most of the comments posted by Slashdotters supported admins, and being a contracted admin myself I have to support them too. I routinely deal with developers who don't test for current versions of Microsoft Windows. Among my clients, the worst are travel reservation network developers who still provide software for 16-bit Windows. Coding for 16-bit Windows is bad enough, but even 16-bit Windows code can function in Win2K or XP as a restricted user, or even with mutliple users, with a little bit of tweaking.

*IX coders know how to program for multiple users and for a restricted environment. They use the environment variables provided by the OS to determine where they should save stuff. Modern versions of Windows make it easy to do the same thing, even if you don't want to use Win32-proprietary constructs like the Registry. For example:

  • %USERPROFILE% = $HOME - if %HOME% doesn't already exist, look for %USERPROFILE%.
  • %ALLUSERSPROFILE% is a place to store per-machine settings, like license keys, terminal addresses and so on. Normally, only Administrators can write here, but everyone can read from here.
  • Items written to %USERPROFILE% automatically follow the user around in their roving profile, if roving profiles are in use on a network. Another possibility, like Galileo uses, is to let the installer specify a network drive for user settings and use the user's home directory (H: or Z: usually). Just make sure your users have this drive, and spell out the requirements in your install guide so guys like me aren't scratching their heads.
  • For "Bob's" sake, don't automatically install in C:\(whatever). Use Installshield or Windows Installer to package your app, and let it find where "Program Files" is. Smart admins like me will restrict access to the root of hard drives so users aren't tempted to store stuff there, and not get backed up on the servers.
  • Test, test, and test some more. Give your customers perks for testing your software, and be prepared to receive feedback. Lots of it.
  • If you use the Registry, store in HKEY_CURRENT_USER first. Only store machine-specific stuff in HKEY_LOCAL_MACHINE and expect that most of your users won't be allowed to change stuff there.
  • 16-bit coders: %WINDIR% is NOT where you store stuff! Give us the chance to specify an alternate location to store stuff. Sabre has a "Userdrive" setting which you can change to a home drive but there's no installer option for it. Don't expect to have write permissions in %WINDIR%.
  • %TEMP% != %WINDIR%\TEMP - Win2K and XP change %TEMP% for each user using short filenames, and is recognizable by 16-bit Windows apps.
  • If you code for Java, including Sun's JVM, look at the Java environment for where you should save settings. It's much the same. Why, oh why does Sabre for Java store its settings in C:\SABRE instead of %USERDIR% or whatever it's called?

See? That wasn't hard.

If you are a developer who deals with the travel industry, expect to see more of me. I'll gladly hand you a copy of this rant if you need help. Oh, and I also test applications for a measly C$30.00/hour. Take advantage of it.

User Journal

Journal: I'm not pro-Microsoft, I'm anti-Idiot.

Journal by gfecyk

Wow, I have a journal space? cool.

I'm glad you poked in here, whoever you are. Let me make your visit here worth while.

I tend to post somewhat pro-Microsoft comments, not so much because I'm pro-Microsoft, but because I'm anti-idiot. I run a small consulting business and all of its clients run some form of Windows, and I've done this for ten years now. So I'd like to think I know what I'm doing.

I've seen most everything that happens to hapless Windows users but once in a while something surprises me, like the Messenger pop-ups, and I shift my approach. For example, it wasn't until those started happening that I began recommending hardware firewalls, because disabling NetBIOS over TCP/IP was enough. With Win2K and XP no longer depending on NetBIOS, that wasn't an option anymore. That shift proved invaluable when Blaster & Welchia hit, because folks who were blocking Messenger pop-ups were already safe from them.

I don't patch every time Microsoft releases an update, because my approaches tend to catch problems like that before the fact. I can then relax until the next Service Pack comes out before harassing clients to do their patching. I also rely on as much built-in stuff as I can, like running programs as a restricted user instead of as Administrator - after all no one runs their apps as root, right? - and my clients do the same thing.

Every computer system has vulnerabilities, and they all get fixed as they're discovered. The best I can do is try to catch problems before the fact.

You can learn about my consulting business at my web site. And hey, if you have to deal with idiots running Windows and want to save them from themselves, give me a call.

The bogosity meter just pegged.

Working...