A single line assignment filled with epic fail

Today I've been working with a piece of third-party software. I was having big problems getting it working and decided to delve into its source (which was included).

I'm not going to name the application (and I've obscured the details below), but the bug is so epic that it manages to combine on a single line four separate types of bugs: a design bug, two implementation bugs, a security hole and an out of date comment.

The program needs to copy a file into a directory. In the process of doing so it sets write permission on the directory into which the file will be copied. The first bug is the design: the program shouldn't be updating permissions on a directory without the user having requested the change. If the directory isn't writable an exception should be generated and an appropriate error displayed.

This particular JavaScript program avoided all that by just setting write permission. It did it like this:

dir.permissions = 666; // Make the file writable


dir is an object that points to the directory to be written to and the permissions attribute allows direct 'chmod' style updating of UNIX-style permissions. Setting the permissions to octal 666 sets read/write for the owner of the directory, the group the owner belongs to and everybody else. It also removes execute permission. In the UNIX world execute permission on a directory means that you can CD into it; with it removed the directory cannot be accessed (i.e. you can't get a list of the files in the directory). That's bug number two.

The third bug is the security hole: by setting read and write for owner, group and everyone absolutely anyone can read and write to the directory that the user was trying to copy a file into. Imagine doing that on your My Documents or similar.

The fourth bug is that the implementer has accidentally used decimal 666 and not octal 666 (which should have been 0666) which means that they are doing the equivalent of octal 1232 which gives the owner of the directory just write permission, the group write and execute and everyone has permission to write. So the permissions are totally wrong.

The extra 1 at the beginning sets the sticky bit whose effect will be platform dependent.

And, finally, bug number five: the comment is incorrect. The permission change is happening on the directory and not the file. Worse, it's the permissions on the file that the coder was originally trying to change by introducing this one line change.

The 2009 Spam Conference at MIT

For reasons unknown to me the Spam Conference in MIT for 2009 is happening but is not being advertised on the usual http://spamconference.org/ URL. If you are interested in attending then you need to hunt down the page http://projects.csail.mit.edu/spamconf/.

There you'll find that the conference is taking place March 26-27, 2009 at MIT and you'll also find the Call for Papers. The submission deadline is March 9, 2009 and the topics being accepted are:

• phishing, spyware
• spit (spam over internet telephony)
• spim (spam over instant messenger)
• SMS spam
• MMORPG spam
• blog spam
• trackback spam
• image spam
• stock pump-and-dumps
• email con games
• exploit marketing
• identity theft
• zombie bots and bot armies
• antispam systems
• hardware antispam countermeasures
• software antispam countermeasures
• wetware (a.k.a., liveware, meatware, i.e., user errors)
• blue-ware (i.e. employing the police).