Is your shift key broken or are you too lazy to use it?

i completely disagree, i have never had a problem scanning directories that my script created, whether it be created on the fly or be created statically. the average user of said compiled prgram isnt going to even know the directory was even created, much less change it contents. not to mention, you could lock the dir or every file in it,

Bullshit. The problem is not the average user, the problem is the malicious user that can abuse a pp-bundled perl script to gain more privileges on the system or to execute a denial-of-service attack. Also, locks on linux are advisory, not mandatory, unless you explicitly enable mandatory locking (1, 2). So, you CAN'T "lock" a directory so that is invulnerable, unless you have tuned the system to allow mandatory locks AND explicitly enabled them for all files by setting proper permissions for each and every temp file created by pp.

also i think you are way off in left feild. if you have 100 pp programs running, then you will have 100 "temp" dir.. then when you run your program it will scan the dirs, then create its own. which can easily be singled out and filtered. i honestly dont know where the other stuff you mention would even come into play while /just/ scanning directories tbh

The "other stuff" explains why it is a stupid idea to use pp, especially on systems derived from Unix.

EDIT: the only thing that could be a problem is if the script/exe created the dir BEFORE the directory could be scanned.

I see lots of problems:

What algorithm is used to determinate the name of the temp directory?

If the name can be determinated before the pp-created executable is started, several trivial attacks are possible. See 3 for some examples.

What permissions are used for the temp files and directories?

You don't want to allow group or world access to temp files and directories, for the reasons shown in [3].

When are permissions set for the temp files and directories?

Creating a file / directory with liberal permissions and then changing them to 0600 or 0700 is yet another race condition. The operating system may switch to another process during every single syscall, so another process may change the filesystem between creating the file and the chmod call.

How are symlinks handled while creating temp files?

You don't want to follow symlinks to vital files like /etc/passwd. See [3].

How are symlinks handled while deleting temp files?

Imagine a stupid directory deleter, as posted in Re: Copy folders (Re^2: Copy folders explains some of the bugs). Remove your temp files and vital system files are "magically" gone, because someone could insert symlinks into the temp directory and make root execute a pp-packed script including a stupid directory deleter.

And these are just the most trivial problems.

Did you actually follow the Java nightmare link and read the text there? You don't have to understand the unserialize problem, it's a nasty bug, caused by lazy people trusting unverified data, but that's not the real problem. The real problem is that a lot of software from the Java world bundles its own copy of the vulnerable libraries, often hidden inside archives. pp-bundled libraries have exactly the same problem. But because pp stuffed everything into a single executable, it is even harder to find problematic libraries than in the Java world, where you could at least try to search for *.jar and *.class files.

Alexander