Для целей контроля доступа содержимое каталога - это имена файлов, содержащихся в нем. Для добавления, удаления или переименования файлов требуется доступ на запись в каталог. (А чтобы перечислить имена файлов, необходим доступ на чтение). Кроме того, для каталогов существует липкий бит (+t
), который дополнительно ограничивает удаление файлов владельцем файла и владельцем каталога. То есть, он не позволяет удалять файлы, принадлежащие другим, даже если у вас есть доступ на запись в каталог и вы можете изменить его содержимое.
Что касается прав доступа, то их может изменить только владелец, а владельца файла может изменить только root. Я думаю, что редактирование расширенных атрибутов связано с доступом на запись, поэтому вы не можете запретить это отдельно.
Что касается ваших требований, если я правильно понял, вы хотите разрешить создание файлов внутри ${ROOT}/build
и ${ROOT}/config
, но не в других каталогах под ${ROOT}
. Это будет сделано просто:
chmod a+rX -R ${ROOT}
chmod o-w -R ${ROOT}
chmod o+w -R ${ROOT}/build ${ROOT}/config
# chmod +t -R ${ROOT}/build ${ROOT}/config
На самом деле здесь нет необходимости использовать бит immutable, он специфичен для файловой системы и одинаково ограничивает всех пользователей, включая владельца и root.
Однако, если сборка будет происходить внутри ${ROOT}/build
, все еще остается проблема, что несколько пользователей не смогут работать, не задевая файлы друг друга. Чтобы решить эту проблему, вы можете модифицировать систему сборки, чтобы она поддерживала создание сборок в произвольных выходных каталогах, или просто позволить каждому пользователю создавать свою собственную копию дерева исходников и компилировать ее в своих домашних каталогах.
То, о чем вы просите, как написал Томас Дики, это кросс-компилятор.
Их не сложно сделать, но их очень утомительно настраивать и поддерживать правильную настройку, потому что есть много зависимостей от целевой системы, которые должны быть учтены, чтобы собрать правильный исполняемый файл.
Каковы некоторые из этих зависимостей? Вот лишь некоторые из них:
функции main()
. long
". Они могут отличаться, поэтому вам нужна, за неимением лучшего слова, целевая реализация. В общем случае, это означает, по крайней мере, все заголовочные файлы для вашей целевой системы, которые являются "частью реализации". Определение того, какие из них вам нужны, а какие нет, в лучшем случае является утомительной задачей. Так что просто возьмите их все, верно? Ну, это увеличивает количество зависимостей, о которых вам придется беспокоиться. Итак, для создания кросс-компилятора вам нужны заголовочные файлы, библиотеки и стартовые двоичные файлы/код для вашей целевой системы - и как только вы его установите, вы должны поддерживать его - если целевая система получает исправления, которые влияют на ваш кросс-компилятор, вам нужно воспроизвести эти изменения в вашем компиляторе. Как вы определите, что патч "123456" или RPM "abc" влияет на ваш кросс-компилятор?
И, возможно, я многое пропустил.
Должно быть совершенно очевидно, почему никто не беспокоится о кросс-компиляторах, когда целевой системой является что-то, что легко создать на аппаратном обеспечении x86, например, Linux/Solaris/Windows/BSD, и даже почему, когда целевой системой является что-то более сложное (например, Solaris на SPARC), почти все, кому нужно компилировать для этой цели, просто покупают для компиляции какое-то low-end совместимое оборудование.
Вы можете установить VirtualBox (или какое-либо другое программное обеспечение для виртуальных машин) на свой компьютер Debian и установить Solaris в , . Oracle (поставщик) предоставляет загрузки .
Если университетский компьютер совместим (на базе x86, аналогичная версия), можно будет компилировать локально и использовать исполняемые файлы на другой машине.