> Here's my kernel patch. This one should finally (?) stop typical > race conditions, including pipe attacks and regular file races. > This solution is radical (disallows writing to not-your pipes and > files in +t directories), but works fine. Even if any program > fails, it may be easily patched to store it's files in eg. /tmp > subdir. It's much easier to change one path than to fix a lot > of vunerable utilities. I must say this, though I suspect Aleph1 will be starting to get annoyed at both sides of this silly discussion: I am quite fascinated at the extent to which people will go to avoid fixing the /tmp races in the programs in question. To me it is quite clear that your patches are breaking the expectations which regular code has in a POSIX/UNIX environment, ie. expectations that /tmp works. Perhaps your next patch will make it impossible to create directories or files in /tmp. Because, as I am sure you do realize, it is very easy to effect denial of service attacks by creating a directory where a program expects a file, or a file where a program expects to create a directory. So... how much longer is this futile slashing going to continue?
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:43:06 PDT