Checking for programs that call open(2) with O_CREAT and don't specify a mode. It's a terribly easy thing to look for and can be an annoying bug. As for having students do it, it has the advantage of making them do some code analysis since not all botched open calls are security issues. If I call open as such open("/tmp/feh", O_CREAT); I end with a file called /tmp/feh with nearly random permissions (bits are sucked off the stack to set the permissions). It's possible the file could be written as world writable (or many other permissions, I'll let you think about the possibilities). I should have called open like this open("/tmp/feh", O_CREAT, 0); Or if I don't want to change the permissions later, I can supply a non zero mode. It's also a fine idea to look for improper usage of temporary files. Using mktemp(3) instead of mkstemp(3). If I could suggest part of your class teaches responsible and sane disclosure. A while back another CS teacher did a similar thing with a class, and at the end of the class dumped a big email to full-disclosure detailing the problems. Luckily none of them were that terribly critical, but there was much scrambling since triaging 30+ issues is painful. Part of finding and fixing security issues is communicating the fixes upstream and deciding what to do about disclosure. I love hearing about classes such as this, good luck :) -- JB