Race conditions accessing files

After a brief thread with smb4k upstream, I noticed that it is not evident for many developers that accessing files (temporary or not) could expose to race conditions exploits in some situations, if the program runs in privileged mode or not. That's quite worrying, because Debian GNU/Linux has tons of little tools which are not so often inspected for security auditing. So folks, be so nice to read the following recommendations and consider that accessing files could be potentially a risky business:

• do not use fixed or easily guessable pathnames for files in /tmp or any other world -accessible directory.
  
• do not use nothing different from mkstemp() or tmpfile() to open temporary files and consider that mkstemp() does not work properly on NFS (due to O_EXCL use)
  
• double check if you are using correct ownership and permission
• unlink temporary files just after opening and use the open handle after
  
• check if you are accessing a symlink or a pipe and do not accept anything different from a plain file
• do not accept any path which has a symlink in a subpath
• do not overwrite an existent file and if your temporary files need explicit deletion do not forget to do it on exit
• checks and opening must be done atomically
• tempnam() and its sister calls are evil
• creating a temporary directory and files there is better for atomicity against race conditions
  
• doing IPC without a named file is surely safer

Proftpd 1.3.0 is going ready

New version of proftpd will use DSO, that caused a complete rewriting of the packages in sid.
That's a good news, because it will allow a simplified approach, without the need of using many different flavors of binaries for every authentication layer. Also, I'm moving to dpatch and removing all dbs patching rests. The bad news is of course that the new package will delay and stay in experimental too for a while eventually. Anyway I have not intention to release until 1.3.0 will become official for TJ and the Proftpd team. In the meantime I'm cleaning the 1.2.10 release by removing a whole series of imperfections and little bugs.

The proftpd saga

I'm receiving almost no-end off-BTS reports about sarge proftpd package (1.2.10-15). It is amazing to see how few people care to consult the Debian Bugs Tracking System to know possible issues and problems with Debian packages. The old package in stable has a few gotchas (segfaults and cpu hogging) due to mod_delay module, which stabilized only recently, about one month or so after sarge release.

My suggestion is using 1.2.10-20 release on any production server, if you would not experiment DoSes and CPU consumption under heavy load. I packaged a stable backport with needed patches and uploaded to my own repo sitory on people. You can also add an apt resource like:

deb http://people.debian.org/~frankie/debian/sarge/ ./

I hope a proposed update with those changes enter a next point release of sarge. Incidentally, -20 solves also a couple of security issues pointed recently by Secunia and full disclosed since then. They will be object of a secure team update (thanks Michael Stone), due in a few.

Frankie's World blog started

Ok, time to start blogging Debian activities, just to inform a few people about flaws and status of my packages and whatever...
Blogging is also the stardard way to complain about Debian issues too, as we recently discovered :-)