Python 2.6中subprocess.call（）似乎被调用setgid的行为触发Perl的感染检查。我该如何解决？

Question

我有Python的subprocess.call（）和使用os.system（），似乎setgid程序有关系之间的一些奇怪的行为差异。要调用导致Perl的感染检查的区别时subprocess.call（）时，其产生问题，因为我没有修改所有，将需要加入到他们解除污染代码的Perl脚本的能力。

实施例， “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";

在输出 - subprocess.pl的两个试验应该是相同的，但与subprocess.call（一个运行）得到一个污点错误：

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>

在使用使用os.system（）的作品，我真的宁愿使用subprocess.check_call（），因为它更向前兼容，并具有良好的检查行为。

任何建议或文档，或许可以解释为什么这两个有什么不同？是否有可能，这是在被调用这些行为在我的本地UNIX环境中一些奇怪的设置？

Answer 1

我觉得你的错误是用Perl，或者它与你的环境交互的方式。 你的反引号过程调用由于某种原因setgid的。我可以复制这个问题的唯一办法，就是setgid程序放在/ usr / bin中/ perl的（-rwxr-SR-X）。 [编辑]具有蟒setgid的做到这一点也！

[编辑]我忘了使用os.system 是为你工作。我觉得这里的唯一的区别是，与使用os.system环境的不的继承了子进程。翻阅各子进程的环境中，你会发现你的罪魁祸首。

Answer 2

不会发生对我来说：

$ 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

什么是您的版本号？

在什么样的帐户，你运行？

编辑：

对不起无缘冠军 - 我没有蟒蛇2.6随时随地轻松访问，所以我不得不离开这个问题

编辑：

所以看起来我们的工作出了问题 - SGID蟒2.6二进制

这也将是有趣的，如果子与所述外壳还避免了该问题。