Doesn't this just move the problem down one step, as now you have to be sure the directory you try to create doesn't exist?

@trlkly that is handled by mktemp

To play Devil's Advocate:  Does mktemp somehow prevent any other processes accessing the directory, once created?  If not, isn't there the (miniscule) possibility that another process could spot the directory and create a file in it before this process does so?

@gidds, it does set the permissions so that only you can access it, but if there's a malicious gremlin running under your permissions (or root), then yes, they could possibly do that.

@gidds If you have a rogue process running in the same security context, or a more privileged one, then all bets are off. There is also a (miniscule?) possibility that it will modify the script being tested, or modify a shell configuration file, or take some other action that makes the current discussion moot.

@gidds yes, that is possible (although unlikely). But remember that this rogue process would need to not only find/guess the name of the temp directory, it would have to do so in the milliseconds this near-instant script would be running, and it would also have to guess the name of the file I am testing for. We could trivially extend this to generate a long, random alphanumeric file name which would be created at runtime, not written into the script. That makes it next to impossible for any process to create it.

@terdon The rogue process could monitor file system changes, and it could have any length of time to process them (the OP does not say how long their tests take).

@BrianDrake sure. But I just don't see why that's relevant. This isn't about some sort of cryptographically secure system. We're talking about a simple method to debug a program. If we need to consider things like what you describe, we have far more serious issues on our hands. Also, the test is very, very fast. Even in as slow a language as bash, that script ran in 9 milliseconds on my machine. I just don't see the point on considering extreme edge cases for something that is really just a debugging tool.

@terdon Regarding your edit, a plain mktemp -d already uses a random name (at least in my tests); your “paranoid” code merely adds more randomness for no real reason.

What about a plain mktemp -d, @brian?

@terdon, with something like inotify, the attacker doesn't need to guess. They do need to be faster than the script, though, but that's also not impossible. Especially against a script that launches other processes to do some work, a C program built for the purpose would have an advantage from the go, etc. This is really not an argument against mktemp, since if the adversary runs with the same UID, they can do a lot more. But if we were talking about potential symlink attacks/TOCTTOU attacks doable by other users, all that would be very relevant.

@ilkkachu how would inotify help guess the file name of a file that the script does not create? It could find the temp dir, yes, but the specific file name being checked for? I mean, this entire discussion seems irrelevant, the OP just wants a quick little test for debugging so I really don't understand why people are now imagining some sort of attack scenario. But even in that scenario, I don't see how inotify would help find the name. (whoops, I just realized my previous version was creating the file and in the directory we check for no less. Duh)

@BrianDrake the final paranoid version (the first was wrong, I was actually testing for the file I'd created like an idiot, but is now correct) doesn't create a file at all. Only a directory. So even if for some reason I don't understand someone would want to use this in some sort of secure scenario (which is not what the question is about), it would still be next to impossible for another process to find the right file name to create and, if some process can do so, then your system is so compromised that you may as well go home.

@terdon I missed the fact that both the directory and the file within the directory would have random names, so there are two random names involved. I am guessing that ilkkachu made the same mistake.

@terdon, yes, you're right, it doesn't help guess the random filename if you don't create it. And yes, you're also right in that the whole question is moot, since (like I said) if there's an adversary running with the same privilege, they can do a lot more than guess. E.g. they could give the script a PATH containing modified copies of mktemp and head... Or modify the script itself.

@terdon, anyway, that one with the mktemp XXXXXXXXXX... leaves the temp file laying around in the current directory. (And honestly, tr -dc A-Za-z0-9 </dev/urandom is just ugly, but nevermind.) I'm just not sure what you're guarding against with those variants. Brian said two hours ago that all bets are off if there's a malicious process running at the same privilege. You said it yourself that if we need to consider issues like that, we have bigger problems.

@ilkkachu quite frankly I'm guarding against even more comments arguing what I feel are completely irrelevant minutiae about absurd scenarios of attack. Since people keep commenting, I am adding stuff to appease them in the hope that I can stop receiving notifications. I now delete the tmp file which I had forgotten.

@terdon My first response to gidds was simply to explain that we cannot guard against a privileged malicious process; this is where the discussion should have ended. I am not sure how we ended up with this crazy sequence of edits (that frankly I cannot be bothered reading anymore). Not all comments warrant edits!

Would it work if this method was used with some regular file much more assured to exist, like maybe /bin/cat ? I.e., [1] test for /bin/cat, [2] place a lock on it, [3] test for /bin/cat/foo which should not exist and [4] release the lock?

@RossPresser no. What if I run sudo rm /bin/cat; sudo mkdir /bin/cat. The idea here is to avoid making assumptions like "should/should not exist" as much as possible by controlling the file/dir creation process.

I actually meant to post that comment on Kamil's answer, but thank you for the reminder that root can do things even when a user thinks he has the file locked.

@terdon, well, the problem (my opinion) with going down that rabbit hole is that it distracts from of the solution (a good solution!) you had originally, wastes your time, and brings up new issues that may warrant comments or ironing out. E.g. I commented on the "the script is fast" subject not because it'd be a relevant issue here, but because in general, it doesn't work as a defence. There's been a number of symlink/TOCTTOU vulnerabilities in the real world proving that, and I wouldn't want to allow bad security practices get perpetuated.

In any case, we already assume in all answers that the system in general is somewhat sensible, and don't try to guard against an environment where the usual security barriers have already been breached. Perhaps I should have been more clear in shooting down gidds' suggestion that a malicious program running with enough privilege could eff this up, exactly because given a sufficiently broken environment, anything is impossible to safely. Honestly, I think you could have just left the answer at revision 2, but I understand that saying it now might not feel that helpful. Sorry.

For the file name, instead of tr -dc A-Za-z0-9 </dev/urandom, you might as well do tr -d '/\000' </dev/urandom. :-)

Holy smokes, what craziness! ;) I have been on the receiving end of such comment storms, @terdon, and can heartily encourage you to judiciously ignore additions if you feel they don't add more to the answer. In this case, OP gives no hint that malicious attacks or weird edge cases interest them at all... this muddles up a very clear answer more than necessary. Might I suggest you split your now very long answer in two clearly labeled parts (I like "##" for subtitles); the first where you succinctly point out your mktemp solution, and a further "addendum" where you put all the other stuff?

@AnoE And yet, you just added +1 to the storm. :-))