Система тестирования

> исследовать файловую систему, что-то удалять, что-то записывать,

Установить корректные права на каталоги ФС, запускать программу из под пользователя с очень ограниченными правами. Возможно даже в chroot-е.

> открывать порты

Настроить iptables

> и т.д.

В общем это рядовая задача, которая решается средствами ОС.

Самому интересно.

Можно запускать прогу с LD_PRELOAD="fake.so" в которой будут переопределены вункции open, read, write и если что не так - выходить с ошибкой. Для программ использующих glibc покатит.

А если будут использовать системные вызовы? Афаик, нужно смотреть в сторону SELinux, там можно вроде добавить правило, по которому будет запрещено открывать файлы. Ещё как вариант, искать названия типа "open(" , и не разрешать компилировать такой файл.

qemu ?

>А если будут использовать системные вызовы?

системные вызовы этот хук тоже перехватывает.

User-mode Linux, наверное, тоже можно.

Системный вызов это команда процессора int num, перехватывать её можно либо из отладчика, либо эмулируя виртуальный процессор.

Да, я думал про виртуализацию. Вот что рассматривал: http://linux-vserver.org. Но не будет ли это "из пушки по воробьям"?

В ядре с недавнего времении появилась фича secure computing (CONFIG_SECCOMP), как раз для контроля за untrusted кодом, может помочь (прочим ограничениям безопасности, разумеется).

> Системный вызов это команда процессора int num, перехватывать её можно либо из отладчика, либо эмулируя виртуальный процессор.

в БСД есть systrace:

       SYSTRACE(4)

NAME
     systrace -- enforce and generate policies for system calls
...............
HISTORY
     The systrace facility first appeared in OpenBSD 3.2, and then in
     NetBSD 2.0.

Посмотрите на www.ejudge.ru

> Посмотрите на www.ejudge.ru

Благодарю. Интересно будет посмотреть на архитектуру подобной системы. Кстати, если кто-нибудь знает еще подобные open-source проекты - скидывайте, пожалуйста, ссылки, не стесняйтесь.

Возвращаясь к ejudge. На первый, взгляд они выбрали не самое удачное решение - патч к ядру. Во-первых, неосторожный kernel-space programming (без особой нужды) может вызвать сбой всей системы, во-вторых, надо обновлять патч для каждого нового ядра, наконец в-третьих, необходимо перекомпилировать ядро для установки программы - это значительно усложняет deployment. Лучше, наверно, выбрать одну из существующих систем виртуализации.

OMFG! Заглянул в исходники ejudge и обомлел: у них там веб-интерфейс реализован на _С_!

  fprintf(f, "<select name=\"language\"><option value=\"\">\n");
    for (i = 1; i <= state->max_lang; i++)
      if (state->langs[i] && !state->langs[i]->disabled) {
        fprintf(f, "<option value=\"%d\">%s - %s\n",
                state->langs[i]->id, state->langs[i]->short_name,
                state->langs[i]->long_name);

Страшно прям до обморока.

А по-моему очень даже не плохо выглядит. Да и работать должно лучше всяких там .....

p.s. Хотя "web" вообще зло.

Виртуализация -- как-то совсем тяжело для такой задачи. Я бы использовал BSD jails

Да, патч к ядру затрудняет деплоймент, к сожалению.

Впрочем, этот патч существует с 2000 года, работает на нескольких production-серверах и проблем со стабильностью нет никаких.

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

Насколько я понимаю скорость исполнения здесь не обязательна. Если так, то можно использовать какаю-нибудь платформу на основе виртуальной машины и мощной системы безопасности (например, Java или .NET). Перед тестированием компилируем исходный код в байт-код и запускаем внутри sand-box. Единственное требование - все эти языки должны компилироваться не своим "родным" компилятором, а на целевую платформу, например C -> Java byte-code или С -> .NET IL code.

На данный момент таким образом проблема решается только для Java, так как для .NET в Mono безопастность не реализована, а C/C++/Pascal компилировать в байт-код Java или .NET невозможно.

> для .NET в Mono безопастность не реализована

Не знал. Неприятно удивлен. Неужели это правда?

> C/C++/Pascal компилировать в байт-код Java или .NET невозможно.

Для С/C++/Pascal -> .NET доступны виндовые компиляторы, например, умеющий генерить managed код для C/C++ компилятор msvc . Есть ли такие компиляторы для Java - не знаю. Кроме того, кажется, существует такая тулза (commercial ??), которая умеет выполнять IL код средствами Java VM. Есть и обратная тулза (open-source) для Mono.

Обычный C или C++ в полном объеме в managed код компилировать невозможно, и таких компиляторов не существует. Компилятор MSVC поддерживает "Managed C++", а это не то же самое, что нормальный C++.

> Обычный C или C++ в полном объеме в managed код компилировать невозможно

Вы в этом уверены? Почти та же машина Тьюринга, только вид сбоку. Кстати, "Managed C++" - уже удел прошлого и тупиковая ветвь. Сейчас там у них C++/CLI.

В любом случае, по subj мне попадался на глаза открытый проект по компиляции C -> Java byte code. Правда не знаю, на какой стадии сейчас он находится.

При использовании Java можно охватить достаточно большое количество языков, например, (Small) Eiffel, Python, Ruby и т.д. В случае .NET их количество еще больше. Видимо, вопрос нужно ставить так: какие именно языки должны поддерживаться такой системой тестирования? А уже дальше смотреть по списку.

> Почти та же машина Тьюринга.

LOL И сколько же времени будет работать такая "машина Тьюринга" по сравнению со скомпилированной программой???

Для сведения: когда говорят о машинах Тьюринга всегда рассматривают полиномиальную сводимость алгоритмов. То есть работает ли программа за время O(n) или за время O(n^100) - не важно, главное, чтобы не за O(2^n)... Поэтому разговоры о машине Тьюринга в контексте задач с жестким ограничением по времени довольно забавны...

> В любом случае, по subj мне попадался на глаза открытый проект по компиляции C -> Java byte code.

Ну, мало ли чего бывает в интернете...

> LOL И сколько же времени будет работать такая "машина Тьюринга" по сравнению со скомпилированной программой???

LOL. В самом начале у меня было написано, что если "скорость исполнения здесь не обязательна (имеется ввиду, что важна)", то ...

В общем, если ты - автор топика, то мне все понятно. Мне здесь больше делать нечего. Чур меня еще спорить на такие темы.