C ++: Какая альтернатива системе (…) является кроссплатформенной и безопасной?

Question

C ++: Какая альтернатива системе (…) является кроссплатформенной и безопасной?

0

Я хотел бы использовать system(...) в C++ для выполнения других исполняемых файлов. После некоторых исследований кажется, что все думают, что system(...) является наихудшей вещью когда-либо, и никто не должен ее использовать, если они абсолютно не нужны, потому что это

ресурс тяжелый
не гарантируется работа на всех платформах
антивирусное программное обеспечение часто считает его злонамеренным
могут быть легко использованы/могут непреднамеренно запускать неправильные программы

Итак, есть ли альтернатива system(...) которую я должен использовать? Я нахожусь в Linux, но мне хотелось бы, чтобы это была кросс-платформенная (по крайней мере, между Linux и Windows).

nneonneo 12 авг. 2014, в 06:08

Источник

1

Для кроссплатформенной работы system() является переносимой (это стандарт C, а следовательно, и стандарт C ++). Любая альтернатива зависит от платформы. Комментарий «не гарантируется работа на всех платформах» является странным; не ясно, какой смысл делается. Если вы составляете сложную командную строку с большим количеством метасимволов (перенаправление ввода / вывода, кавычки и т. Д.), То вы ограничиваете шансы работы команды на разных платформах. Но для простых команд с простыми аргументами это будет работать нормально. Что касается запуска неправильных программ, это зависит от того, как вы строите имя команды, но детали зависят от платформы.
Jonathan Leffler 12 авг. 2014, в 04:06
0

@JonathanLeffler, так ты думаешь, будет нормально, если я использую system() ? Это снижает производительность запущенного приложения?
user3835277 12 авг. 2014, в 04:08
0

system НЕ портативна; Вполне возможно (и хорошо), что его можно игнорировать, чтобы он выполнялся по-разному на разных платформах, и чтобы происходили различные неприятные побочные эффекты! Он вызывает «командный процессор», который очень хорошо может не существовать (например, во встроенных системах).
Alice 12 авг. 2014, в 04:10
0

@Alice Алиса, но что, если я знаю, что все платформы, с которыми я буду работать, имеют командный процессор?
user3835277 12 авг. 2014, в 04:18
0

@gragas: Gragas: Это зависит от того, что вы планируете делать. Если вы просто намереваетесь запустить простую программу с простыми аргументами и убедитесь, что это именно то, что вы делаете (проверяя любой ввод пользователя и среду), вы можете использовать system() . Альтернативой является создание более подходящего интерфейса и его реализация отдельно для каждой платформы, содержащая переносимость в код, который работает (более или менее) как суррогат для system() . Однако вам необходимо тщательно определить этот интерфейс. Например, вы можете решить использовать int alt_system(char **argv); вместо одной строки.
Jonathan Leffler 12 авг. 2014, в 04:19
0

@gragas Вы не можете этого знать; это не часть спецификации C или требований. И это не касается требований к файловой системе, различных типов командных процессоров (хороший пример - dash vs bash, и давайте даже не будем начинать с powershell). Ни один из них ни в коем случае не является «портативным». Хотя system может работать, для тривиальных примеров, на разных тривиальных платформах, она никогда не должна рассматриваться как переносимая.
Alice 12 авг. 2014, в 04:21
0

@gragas: обратите внимание, что есть большая вероятность, что вам придется адаптировать текст, отправляемый в system() чтобы соответствовать ожиданиям системы, в которой он работает. Вы не сможете использовать одну и ту же строку как в Unix, так и в Windows очень часто, даже если «одинаковая» программа доступна на обеих платформах.
Jonathan Leffler 12 авг. 2014, в 04:21
0

На практике (т.е. без учета того, что говорит стандарт), system для выполнения основных команд довольно переносима в дистрибутивах Linux и Windows. Обратите внимание, что под «базовым» я подразумеваю нечто эквивалентное system("command") .
Rapptz 12 авг. 2014, в 04:22
0

@Rapptz Не правда; для bashisms, различных файловых систем и различий в среде (псевдонимы пользователей и т. д.) вполне возможно превратить основные команды в пыль. Это происходит с пугающей регулярностью.
Alice 12 авг. 2014, в 04:24
0

@Alice Алиса Не ... правда. В Windows это эквивалент cmd /c "command" , в системах POSIX это эквивалент sh -c 'command' . Если command доступна как в Windows, так и в Linux, то она должна (и имеет) работать нормально. Я знаю, что system видится как плохая, но то, что вы описываете, не должно происходить в базовом случае, если вы не делаете какие-то чрезвычайно странные вещи (например, возможную передачу по трубам или запросы файловой системы). По сути, пока вы избегаете функций оболочки, вы должны быть хороши и рисковать безопасностью.
Rapptz 12 авг. 2014, в 04:26
0

@Alice Алиса Ребята, я не могу просто поменять один или два символа при портировании на Windows? Например, версия Linux может быть system("./a.out") а затем версия Windows может быть system("a.exe") .
user3835277 12 авг. 2014, в 04:28
0

@Rapptz Да, действительно. Во-первых, эти утверждения не соответствуют действительности; спецификация не диктует то, что вы сказали. Для system () полностью разрешено вызывать пользовательскую оболочку, а не системную; если один пользователь запускает dash, а другой запускает bash, команда может быть легко проанализирована по-разному. Если псевдонимы существуют для одного пользователя, но не для другого, это может привести к выполнению разных команд (помните, они, вероятно, заранее не знают, какую команду вы вызываете, так как они узнают, что их псевдоним плохая идея? ) system () работает нормально, пока не работает.
Alice 12 авг. 2014, в 04:28
0

@gragas Да, если ваша идея переносимости - это ровно два компьютера, на которых вы ее тестировали. Он не переносим между оболочками, между версиями оболочек, между ОС, версиями ОС или даже разными пользователями. Если вы хотите, чтобы он работал точно на двух компьютерах и, возможно, (но отнюдь не обязательно) на многих других, то да, это можно сделать. Но это не совсем то, что означает «портативный».
Alice 12 авг. 2014, в 04:30
0

Есть два библиотечных решения, которые вы можете использовать. Boost.Process (еще не библиотека повышения) ( highscore.de/boost/process ) и Poco.Process ( pocoproject.org/documentation/index.html ).
Peter R 12 авг. 2014, в 05:32
0

@gragas: Помните, что мнение Алисы о том, что может делать system , не является мнением большинства и, в частности, не разделяется ни одним из существующих разработчиков system , будь то Microsoft, IBM или GCC.
MSalters 12 авг. 2014, в 07:18

Показать ещё 13 комментариев

Теги:

c++

linux

executable

cross-platform

system

2 ответа

-3

Нет; любое такое решение обязательно влечет за собой те же риски. system явно ошибочна, потому что она требует string параметра и использует это для доступа к неизвестной (и не обязательно стандартизованной) файловой системе.

Однако, если вам нужно выполнить другой исполняемый файл в переносном режиме, у вас нет другого выбора; в C/C++ нет концепции процесса (подумайте об этом, вполне приемлемо сделать программу, которая работает без файловой системы, других исполняемых файлов и даже других потоков).

Вот несколько вещей, которые вы можете сделать, чтобы сделать его более безопасным:

Используйте API файловой системы из C++ 11 (или fopen, если вы хотите быть действительно переносимым), чтобы проверить, действительно ли предоставленный файл существует; система может выполнять код оболочки, что может быть опасно.
Не добавляйте специфические вещи файловой системы в строку (например, "../"), потому что файловые системы не переносятся. Вы должны быть в порядке, если программа, которую вы хотите выполнить, находится в том же каталоге, что и исполняемый в данный момент.
Используйте Posix (если переносимость окон не может быть гарантирована) и используйте fork/exec. Тогда у вас гораздо больше контроля.

Boost.Process также может использоваться, если "портативный" означает "переносимый на несколько конкретных платформ, а не эзотерические".

Alice 12 авг. 2014, в 01:08

0

Осторожнее с проверками существования. Защитить от атак TOCTTOU кросс-платформенным способом нетривиально.
nneonneo 12 авг. 2014, в 04:11
0

Кроме того, Windows не поддерживает POSIX. Иногда он поддерживает подмножество POSIX, но соответствие определенно нечеткое. И Cygwin не является идеальным решением для мобильности.
nneonneo 12 авг. 2014, в 04:12
0

@nneonneo В любом случае невозможно использовать систему с какой-либо степенью уверенности. И, как я уже говорил, «если переносимость окон не может быть обеспечена».
Alice 12 авг. 2014, в 04:13

Показать ещё 1 комментарий

Ещё вопросы

Для кроссплатформенной работы system() является переносимой (это стандарт C, а следовательно, и стандарт C ++). Любая альтернатива зависит от платформы. Комментарий «не гарантируется работа на всех платформах» является странным; не ясно, какой смысл делается. Если вы составляете сложную командную строку с большим количеством метасимволов (перенаправление ввода / вывода, кавычки и т. Д.), То вы ограничиваете шансы работы команды на разных платформах. Но для простых команд с простыми аргументами это будет работать нормально. Что касается запуска неправильных программ, это зависит от того, как вы строите имя команды, но детали зависят от платформы.
@JonathanLeffler, так ты думаешь, будет нормально, если я использую system() ? Это снижает производительность запущенного приложения?
system НЕ портативна; Вполне возможно (и хорошо), что его можно игнорировать, чтобы он выполнялся по-разному на разных платформах, и чтобы происходили различные неприятные побочные эффекты! Он вызывает «командный процессор», который очень хорошо может не существовать (например, во встроенных системах).
@Alice Алиса, но что, если я знаю, что все платформы, с которыми я буду работать, имеют командный процессор?
@gragas: Gragas: Это зависит от того, что вы планируете делать. Если вы просто намереваетесь запустить простую программу с простыми аргументами и убедитесь, что это именно то, что вы делаете (проверяя любой ввод пользователя и среду), вы можете использовать system() . Альтернативой является создание более подходящего интерфейса и его реализация отдельно для каждой платформы, содержащая переносимость в код, который работает (более или менее) как суррогат для system() . Однако вам необходимо тщательно определить этот интерфейс. Например, вы можете решить использовать int alt_system(char **argv); вместо одной строки.
@gragas Вы не можете этого знать; это не часть спецификации C или требований. И это не касается требований к файловой системе, различных типов командных процессоров (хороший пример - dash vs bash, и давайте даже не будем начинать с powershell). Ни один из них ни в коем случае не является «портативным». Хотя system может работать, для тривиальных примеров, на разных тривиальных платформах, она никогда не должна рассматриваться как переносимая.
@gragas: обратите внимание, что есть большая вероятность, что вам придется адаптировать текст, отправляемый в system() чтобы соответствовать ожиданиям системы, в которой он работает. Вы не сможете использовать одну и ту же строку как в Unix, так и в Windows очень часто, даже если «одинаковая» программа доступна на обеих платформах.
На практике (т.е. без учета того, что говорит стандарт), system для выполнения основных команд довольно переносима в дистрибутивах Linux и Windows. Обратите внимание, что под «базовым» я подразумеваю нечто эквивалентное system("command") .
@Rapptz Не правда; для bashisms, различных файловых систем и различий в среде (псевдонимы пользователей и т. д.) вполне возможно превратить основные команды в пыль. Это происходит с пугающей регулярностью.
@Alice Алиса Не ... правда. В Windows это эквивалент cmd /c "command" , в системах POSIX это эквивалент sh -c 'command' . Если command доступна как в Windows, так и в Linux, то она должна (и имеет) работать нормально. Я знаю, что system видится как плохая, но то, что вы описываете, не должно происходить в базовом случае, если вы не делаете какие-то чрезвычайно странные вещи (например, возможную передачу по трубам или запросы файловой системы). По сути, пока вы избегаете функций оболочки, вы должны быть хороши и рисковать безопасностью.
@Alice Алиса Ребята, я не могу просто поменять один или два символа при портировании на Windows? Например, версия Linux может быть system("./a.out") а затем версия Windows может быть system("a.exe") .
@Rapptz Да, действительно. Во-первых, эти утверждения не соответствуют действительности; спецификация не диктует то, что вы сказали. Для system () полностью разрешено вызывать пользовательскую оболочку, а не системную; если один пользователь запускает dash, а другой запускает bash, команда может быть легко проанализирована по-разному. Если псевдонимы существуют для одного пользователя, но не для другого, это может привести к выполнению разных команд (помните, они, вероятно, заранее не знают, какую команду вы вызываете, так как они узнают, что их псевдоним плохая идея? ) system () работает нормально, пока не работает.
@gragas Да, если ваша идея переносимости - это ровно два компьютера, на которых вы ее тестировали. Он не переносим между оболочками, между версиями оболочек, между ОС, версиями ОС или даже разными пользователями. Если вы хотите, чтобы он работал точно на двух компьютерах и, возможно, (но отнюдь не обязательно) на многих других, то да, это можно сделать. Но это не совсем то, что означает «портативный».
Есть два библиотечных решения, которые вы можете использовать. Boost.Process (еще не библиотека повышения) ( highscore.de/boost/process ) и Poco.Process ( pocoproject.org/documentation/index.html ).
@gragas: Помните, что мнение Алисы о том, что может делать system , не является мнением большинства и, в частности, не разделяется ни одним из существующих разработчиков system , будь то Microsoft, IBM или GCC.
Осторожнее с проверками существования. Защитить от атак TOCTTOU кросс-платформенным способом нетривиально.
Кроме того, Windows не поддерживает POSIX. Иногда он поддерживает подмножество POSIX, но соответствие определенно нечеткое. И Cygwin не является идеальным решением для мобильности.
@nneonneo В любом случае невозможно использовать систему с какой-либо степенью уверенности. И, как я уже говорил, «если переносимость окон не может быть обеспечена».

nneonneo · Accepted Answer · 2014-08-12T01-34-00.000Z

1

Лучший ответ

Если ваша цель - просто синхронно выполнять подпроцесс, system действительно не плохая ставка. Он определен на C89, поэтому он очень портативен, и производительность не обязательно является проблемой, если вам не нужно запускать огромное количество подпроцессов.

Да, вы должны знать о проблемах безопасности: вам нужно очистить переменные среды и всегда выполнять этот процесс, используя полный путь (когда это возможно), чтобы избежать атак PATH. Кроме того, никогда не используйте внешний вход при построении вашей system команды без надлежащего экранирования.

Если вы будете осторожны с ним, это хороший переносимый способ запуска внешних программ.

nneonneo 12 авг. 2014, в 01:34

1

Это не портативный; между windows и linux, кардинально отличающиеся системы оболочек могут вызывать затруднения в диагностике поведения. Даже между Dash и Bash есть целый список ошибок, с которыми приходится иметь дело. Только используя его чрезвычайно ограниченным образом (и принимая во внимание любые возможные системные различия), он мог быть использован эффективно. Вряд ли портативный.
Alice 12 авг. 2014, в 04:12
1

@Alice: А что бы вы предложили, чтобы он был более портативным и желательно стандартизированным?
Jonathan Leffler 12 авг. 2014, в 04:14
1

Это более портативный, чем буквально любой другой подход. Это то, что я говорю. Если вы хотите отказаться от переносимости, то, конечно, я согласен, что есть лучшие альтернативы system
nneonneo 12 авг. 2014, в 04:14
0

@JonathanLeffler Ничто из того, что я сказал, никоим образом не подразумевало более портативного или стандартизированного решения. Нет портативного решения .
Alice 12 авг. 2014, в 04:16
0

@nneonneo Это не портативно, по причинам, изложенным; здесь нет шкалы переносимости. Это просто не переносимо, и не существует никакого решения, которое было бы каким-либо образом переносимым, потому что сама проблема не переносима; встроенные системы часто не поддерживают такого рода доступ, и они составляют 90% рынка микропроцессоров.
Alice 12 авг. 2014, в 04:18
0

@ Алиса: встроенные системы - это совершенно разные звери. Практически никогда не пишут полностью переносимый код - каждый процессор имеет свои особенности. И ОП явно не спрашивал о встроенных процессорах.
nneonneo 12 авг. 2014, в 04:39
0

@nneonneo Он сказал, что переносимый, а не «переносимый, а только для процессоров, производных от x86, обычно используемых в настольных системах», что, как вы, вероятно, подразумеваете, он имел в виду (поскольку system () не очень хорошо работает в системах ARM, используемых для интеллектуальных систем). телефоны, webos не выдерживает). Говорить «портативный» и думать, что он имеет в виду «на самом деле не весь этот портативный», немного странно.
Alice 12 авг. 2014, в 04:58
0

Какого черта? system () работает на iOS, на Android и на любом компьютере ARM, работающем под обычным GNU / Linux.
nneonneo 12 авг. 2014, в 05:35
1

Согласен с ннеоннео. Вопрос помечен C ++. Это исключает 8051 микроконтроллеры и тому подобное, встроенный C ++ - это Linux / VxWorks и тому подобное. Все они имеют system , даже встроенные системы намного проще , чем Android. Черт, даже у Symbian была system (в lib PIPS)
MSalters 12 авг. 2014, в 07:28
0

Наличие системы не означает, что один и тот же параметр, заданный для системы, будет иметь тот же результат . Это работает, но у него нет переносимых результатов. Разное понимание того, что означает «портативный»; Вы, безусловно, можете выполнить system () портируемо, но будет ли оно делать то, что вы хотите для нетривиальных вводов? На Android и iOS в частности не обязательно .
Alice 12 авг. 2014, в 19:37

Показать ещё 8 комментариев