> This is solved by using the randomized temporary (sub)directory I Well I guess if you're carrying around this dir for anything longer than n-time, and the attacker is your UID, they just cd into it and DoS you there, why such a power would choose to mess with you that way, who knows :) Though I give them credit and do use such tmpdirs to reasonably segregate one app's junk from other app's junk.
> may find distasteful), at least you can use the O_EXCL/link methods to > detect the race, and perform a reasonable number of retries. A var's a var. Yeah, that's the priority I tend to rote security over DoS. >> from where? > This is an annoyingly hard problem. Ideally you want to rely on > standard library functions, so you can make it the problem of the The suffix causing problem as it's not in the standard thus not expected to exist. random(), open() and link() are code loops are there. And if we move more toward applied, configure can assist with finding any other usable subset of funcs/devices. Configure's existance means there are lots of hard problems. I forgot the use case for this suffix?... it's a new file being actively written to in a scratch area... not actually in a maildir/(cur,new), or final mbox location/name, but more likely 'set tmpdir', or more general user or system location. There is rename() for those scratch files when closed.
