In this case, the, admittedly not entirely exhaustive (project time pressures prevailed on us) investigations into problems we were experiencing revolved around the following...

• Remove tainting - perl ran the script
• Change the permissions on the called binarys' containing directory - perl ran the script
• Copy the called binary from the 'open' directory to a more 'restrictive' directory and change to call to an absolute, from a relative, call - once again, perl ran the script

I didn't either go "way beyond making observations", nor "falsely claim the actions were a result of using tainting"

Your claim that "taint checking isn't confined to the code - the checking involves things like [...] permissions on directories" is false. Which also means you couldn't have observed it.

Remove tainting - perl ran the script

Can't be. Tainting doesn't check permissions.

$ cat > child
#!/usr/bin/perl
print("child\n");

$ chmod a=rwx,u+s child

$ ls -l child
-rwsrwxrwx 1 ikegami group 34 2008-12-13 10:39 child

$ perl -T -e'%ENV=(); system("./child") and die("error: $?")'
Setuid/gid script is writable by world.
error: 6400 at -e line 1.

$ perl -e'%ENV=(); system("./child") and die("error: $?")'
Setuid/gid script is writable by world.
error: 6400 at -e line 1.
[download]

With and without tainting, Perl successfully executed the world-writable child ($? != -1).

The setuid thing is a red herring, since, in our case, the binary was merely an e-mail client called indirectly from a CGI script.

I've already shown that executing world-writable files is not prevented by tainting. If it's not setuid, it's something else. But not tainting.

$ cat > child
#!/usr/bin/perl
print("child\n");

$ chmod a=rwx,a-s child

$ ls -l child
-rwxrwxrwx 1 ikegami group 34 2008-12-13 10:39 child

$ perl -T -e'%ENV=(); system("./child") and die("error: $?")'
child
[download]

Even with tainting, Perl successfully executed the world-writable child ($? != -1) and it ran without error ($? == 0).

I have presented a simplified version of the investigations we made - as a direct consequence of which, a multi-million pound project was delivered on time ... just.

BTW, I notice in your example, you run in the CWD and invoke via ./ - have you tried running your script in e.g. $HOME, setting the permissions on /usr/bin to 0755, putting /usr/bin on your path (if it isn't there already) and invoking relatively using $PATH e.g. invocation by `ls`; as in the OP ?

A user level that continues to overstate my experience :-))