A junk PID in the file does not cause any DoS. It only causes the program to
be unable to do a "kiss of death" to the process which has it open. Nor does
mere creation of the file cause a DoS; the file has to be locked and that only
happens as long as some program has a flock() in effect on it.
What *can* cause a DoS is to create the file without world access; this would
prevent a program trying to acquire the lock from deleting it and making its
own lock.
It's easy to trace; either the bad guy created the file, or one of his running
processes has it flock()ed.
As hinted in David Luyer's message, I believe that the fix is:
a) make sure all security holes which allow creation of files in someone
else's name are fixed.
b) "removeuser" of the offender
Actually, I believe in much harsher measures than (b); e.g. forfeiture of a
large security deposit, expulsion/termination, etc. The advantage is that if
you do it once, word gets around and you don't have to do it again. As long
as you continue to play games of who can come up with the more clever
technical ruse, you will have this sort of nonsense as an ongoing problem AND
make the system less usable.
As long as you tolerate anti-social behavior, you'll get it.
This is similar to what we do for private home security. We don't have
absolute safeguards against burglars -- such are extremely expensive,
incredibly inconvenient, and ultimately ineffective against a determined
burglar. Burglars also have to contend with the very real possibility (in the
US, anyway) of armed homeowners and the absurd situation that killing a
burglar has fewer legal consequences than mere wounding. [The US is one of a
few countries in the world where most burglaries take place during the day...]
The problem with such measures as moving the access lock to the same directory
is multiple. It isn't just the symlink/hardlink issue. The file may be
writeable, but the directory isn't. With shared files, you may really need
world access to locks.
I do not believe that shared access (and other desirable functions) should be
held hostage to a few anti-social individuals. The problem, and the remedy,
is with the anti-social individual. A secondary problem is with those well
intentioned but naive system administrators who think that absolute security
against authorized users is a reasonable and attainable goal, and who end up
denying access for legitimate purposes to their authorized users in the name
of preventing abuse of that access.