Python 2.6 subprocess.call (), по-видимому, вызывает поведение setgid, запускающее проверки заражения Perl. Как я могу решить?

Question

У меня есть некоторые странные поведенческие различия между Python subprocess.call () и os.system (), которые, похоже, связаны с setgid. Разница заключается в том, что при использовании subprocess.call () вызываются проверки на заражение в Perl, что создает проблемы, поскольку у меня нет возможности изменять все сценарии 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 () выдает ошибку taint:

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). [РЕДАКТИРОВАТЬ] Наличие Python Setgid делает это тоже!

[EDIT] Я забыл, что 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

Какие у вас номера версий?

Под каким аккаунтом вы работаете?

EDIT:

Извините, пропустил заголовок - у меня нет python 2.6 в любом месте, где легко получить доступ, поэтому мне придется оставить эту проблему.

EDIT:

Похоже, мы решили проблему - sgid в двоичном файле python 2.6.

Было бы также интересно посмотреть, избежит ли проблема подпроцесс с оболочкой.