Python 2.6 subprocess.call() appears to be invoking setgid behavior triggering Perl's taint checks. How can I resolve?

Question

I've got some strange behavioral differences between Python's subprocess.call() and os.system() that appears to be related to setgid. The difference is causing Perl's taint checks to be invoked when subprocess.call() is used, which creates problems because I do not have the ability to modify all the Perl scripts that would need untaint code added to them.

Example, "process.py"

#!/usr/bin/python

import os, subprocess

print "Python calling os.system"
os.system('perl subprocess.pl true')
print "Python done calling os.system"
print "Python calling subprocess.call"
subprocess.call(['perl', 'subprocess.pl', 'true'])
print "Python done calling subprocess.call"

"subprocess.pl"

#!/usr/bin/perl

print "perl subprocess\n";
`$ARGV[0]`;
print "perl subprocess done\n";

The output - both runs of subprocess.pl should be the same, but the one run with subprocess.call() gets a taint error:

mybox> process.py
Python calling os.system
perl subprocess
perl subprocess done
Python done calling os.system
Python calling subprocess.call
perl subprocess
Insecure dependency in `` while running setgid at subprocess.pl line 4.
Python done calling subprocess.call
mybox>

While using os.system() works, I would really rather be using subprocess.check_call() as it's more forward-compatible and has nice checking behaviors.

Any suggestions or documentation that might explain why these two are different? Is it possible this is some strange setting in my local unix environment that is invoking these behaviors?

Answer 1

Doesn't happen for me:

$ python proc.py
Python calling os.system
perl subprocess
perl subprocess done
Python done calling os.system
Python calling subprocess.call
perl subprocess
perl subprocess done
Python done calling subprocess.call

$ python --version
Python 2.5.2

$ perl --version
This is perl, v5.8.8 built for i486-linux-gnu-thread-multi

What are your version numbers?

Under what sort of account are you running?

EDIT:

Sorry missed the title - I don't have python 2.6 anywhere easy to access, so I'll have to leave this problem.

EDIT:

So it looks like we worked out the problem - sgid on the python 2.6 binary.

It would also be interesting to see if subprocess with the shell also avoids the problem.

Answer 2

I think your error is with perl, or the way it's interacting with your environment. Your backtick process is calling setgid for some reason. The only way I can replicate this, is to setgid on /usr/bin/perl (-rwxr-sr-x). [EDIT] Having python setgid does this too!

[EDIT] I forgot that os.system is working for you. I think the only relevant difference here, is that with os.system the environment is not inherited by the subprocess. Look through the environment of each subprocess, and you may find your culprit.