User-driven application
В своих раздумьях о том, как должно работать приложение на django (где хранить конфиги и т.д.) и наблюдая за текущей грызнёй в debian-russian о методах запуска сервисов, я, кажется, вижу некое принципиальное разногласие между двумя парадигмами.
Эти парадигмы можно сформулировать как ответ на вопрос: чьи приложения на машине?
Варианты ответа:
1) пользовательские
2) администратора
Нужно понимать, что под "приложением" понимается реализация любого алгоритма любым способом, выходящим за пределы sandbox'а. Даже если этот выход трижды разрешён пользователем. Разумеется, любой веб-сайт с активным содержимым является приложением, причём приложением опасным (к которому имеют доступ все желающие из интернета).
Итак, парадигма номер один: администратор обеспечивает платформу, разделение прав и ресурсов, а пользователь волен запускать всё, что ему будет приятно. Это классическая парадигма хостинга, на котором разрешено выполнение скриптов. Это же классическая модель виндовой машины. Это же классчиеская модель с ~/bin.
Вторая парадигма: администратор полностью обеспечивает все приложения, которые нужны пользователям, запрещая запуск любых других приложений.
Очевидно, что второй вариант существенно затратнее в смысле администрирования: администратор должен следить за новыми версиями ПО, за тем, чтобы были все нужные программы и не было бы программ лишних. (вопрос обновлений сильно упрощается при наличии системы обновлений).
Первый же вариант очень опасен: пользователь может не иметь нужной квалификации для обновления ПО или просто не придавать этому значения. Запускаемое ПО никак не контролируется, а, значит, может быть запущено, в том числе, вредоносное ПО.
Все варианты между этими двумя, по сути компромисс: "отсюда нельзя, отсюда можно". При этом любая компромиссная политика по сути сводится к первому варианту (пользовательские приложения), потому что если хоть откуда-то, куда пользователь может писать, можно что-то запускать, значит, файл можно скопировать туда и запустить оттуда.
С корпоративным десктопом и сервером всё понятно: они могут полностью следовать второй парадигме, так как есть централизованное управление и представление о том, что "сегодня потребности в масле не имеется". Особо это понятно в условиях корпоративного сервера, на котором нет, как таковых, пользователей (в смысле, людей), а есть лишь заданный набор функционала, который и обеспечивается конфигурированием компьютера.
С "свободными" пользователями ситуация сложнее - они не желают подчиняться единой парадигме, и возникает очевидная мысль: разрешить запускать то, что они хотят.
На самом деле, такая мысль, при чётком разделении между пользователями по ресурсам, ничего в себе плохого не несёт: пользователь рискует только своими данными.
Настоящая задница начинается в тот момент, когда появляются "пользовательские приложения", интегрированные в общую (корпоративную) ИКС Простейший пример: веб-мастер, который "устаналивает сайты" на веб-сервере, администрируемом другим человеком. С одной стороны ответственность за безопасность перекладывается со специалиста (ну, какого-никакого) на человека, который совсем не готов этим заниматься, с другой стороны, ошибки этого человека ведут к компрометации ИКС, важной для многих людей и (формально) находящейся в зоне ответственности администратора.
Таким образом, следует сформулировать следующие выводы:
1) Любые приложения, работающие с правами, имеющими доступ к ИКС (выходящей за пределы одной учётной записи) должны управляться централизовано. Даже если это неудобно. Даже если это связано с необходимостью админу лично грейдить PHPBB.
2) Право запуска "своих" приложений у конечного пользователя должно быть строго ограничено по доступу к общим ресурсам. Единственный метод добиться этого - ограничить права конечного пользователя.
3) Наибольшую проблему в подобном случае доставят девелоперы ИКС. Решением проблемы может быть разделение аккаунта девелопера от аккаунта, с которым девелопер имеет доступ к ИКС. Аккаунт девелопера имеет высокую степень свободы, но при этом не имеет прав. Аккаунт доступа к "настоящей" (не тестовой) ИКС имеет права, но не имеет свободы. Делать ли две машины для двух аккаунтов или нет - вопрос отдельный. Перенос компонент ИКС из "епархии" разработчика в живую ИКС должен выполняться только администратором. Разработчик не должен иметь прав на отладку/отладочный вывод или какие-то "внештатные" операции с работающей ИКС (даже если это удобнее с точки зрения выяснения причин поломки).
Подробнее об ИКС с веб-интерфейсами. Очевидно, что разрабатывая ИКС для внутриорганизационного применения, следует ориентироваться именно на схему с организационной ИКС, но никак не на схему "личного приложения" (хотя бы потому, что ИКС используется более чем одним человеком). Отсюда вытекает "правильность" хранения конфигурации и исполняемых файлов ИКС: они должны храниться либо в специализированном месте, куда его "внедряют" при установке, либо вести себя подобно всему остальному ПО, используя типичные для ОС места хранения конфигурации, исполняемых файлов и т.д. Очевидно, что если приложение планируется обновляться средствами обновления ОС, то первый вариант не может быть принят как режим по-умолчанию, т.к. процесс обновления должен проводить обновление вне зависимости от того, является ли приложение "важным" или же нет. Нестандартное внедрение в этом случае остаётся на совести администратора и предполагает, что обслуживание его целиком и полностью выполняет администратор.
Эти парадигмы можно сформулировать как ответ на вопрос: чьи приложения на машине?
Варианты ответа:
1) пользовательские
2) администратора
Нужно понимать, что под "приложением" понимается реализация любого алгоритма любым способом, выходящим за пределы sandbox'а. Даже если этот выход трижды разрешён пользователем. Разумеется, любой веб-сайт с активным содержимым является приложением, причём приложением опасным (к которому имеют доступ все желающие из интернета).
Итак, парадигма номер один: администратор обеспечивает платформу, разделение прав и ресурсов, а пользователь волен запускать всё, что ему будет приятно. Это классическая парадигма хостинга, на котором разрешено выполнение скриптов. Это же классическая модель виндовой машины. Это же классчиеская модель с ~/bin.
Вторая парадигма: администратор полностью обеспечивает все приложения, которые нужны пользователям, запрещая запуск любых других приложений.
Очевидно, что второй вариант существенно затратнее в смысле администрирования: администратор должен следить за новыми версиями ПО, за тем, чтобы были все нужные программы и не было бы программ лишних. (вопрос обновлений сильно упрощается при наличии системы обновлений).
Первый же вариант очень опасен: пользователь может не иметь нужной квалификации для обновления ПО или просто не придавать этому значения. Запускаемое ПО никак не контролируется, а, значит, может быть запущено, в том числе, вредоносное ПО.
Все варианты между этими двумя, по сути компромисс: "отсюда нельзя, отсюда можно". При этом любая компромиссная политика по сути сводится к первому варианту (пользовательские приложения), потому что если хоть откуда-то, куда пользователь может писать, можно что-то запускать, значит, файл можно скопировать туда и запустить оттуда.
С корпоративным десктопом и сервером всё понятно: они могут полностью следовать второй парадигме, так как есть централизованное управление и представление о том, что "сегодня потребности в масле не имеется". Особо это понятно в условиях корпоративного сервера, на котором нет, как таковых, пользователей (в смысле, людей), а есть лишь заданный набор функционала, который и обеспечивается конфигурированием компьютера.
С "свободными" пользователями ситуация сложнее - они не желают подчиняться единой парадигме, и возникает очевидная мысль: разрешить запускать то, что они хотят.
На самом деле, такая мысль, при чётком разделении между пользователями по ресурсам, ничего в себе плохого не несёт: пользователь рискует только своими данными.
Настоящая задница начинается в тот момент, когда появляются "пользовательские приложения", интегрированные в общую (корпоративную) ИКС Простейший пример: веб-мастер, который "устаналивает сайты" на веб-сервере, администрируемом другим человеком. С одной стороны ответственность за безопасность перекладывается со специалиста (ну, какого-никакого) на человека, который совсем не готов этим заниматься, с другой стороны, ошибки этого человека ведут к компрометации ИКС, важной для многих людей и (формально) находящейся в зоне ответственности администратора.
Таким образом, следует сформулировать следующие выводы:
1) Любые приложения, работающие с правами, имеющими доступ к ИКС (выходящей за пределы одной учётной записи) должны управляться централизовано. Даже если это неудобно. Даже если это связано с необходимостью админу лично грейдить PHPBB.
2) Право запуска "своих" приложений у конечного пользователя должно быть строго ограничено по доступу к общим ресурсам. Единственный метод добиться этого - ограничить права конечного пользователя.
3) Наибольшую проблему в подобном случае доставят девелоперы ИКС. Решением проблемы может быть разделение аккаунта девелопера от аккаунта, с которым девелопер имеет доступ к ИКС. Аккаунт девелопера имеет высокую степень свободы, но при этом не имеет прав. Аккаунт доступа к "настоящей" (не тестовой) ИКС имеет права, но не имеет свободы. Делать ли две машины для двух аккаунтов или нет - вопрос отдельный. Перенос компонент ИКС из "епархии" разработчика в живую ИКС должен выполняться только администратором. Разработчик не должен иметь прав на отладку/отладочный вывод или какие-то "внештатные" операции с работающей ИКС (даже если это удобнее с точки зрения выяснения причин поломки).
Подробнее об ИКС с веб-интерфейсами. Очевидно, что разрабатывая ИКС для внутриорганизационного применения, следует ориентироваться именно на схему с организационной ИКС, но никак не на схему "личного приложения" (хотя бы потому, что ИКС используется более чем одним человеком). Отсюда вытекает "правильность" хранения конфигурации и исполняемых файлов ИКС: они должны храниться либо в специализированном месте, куда его "внедряют" при установке, либо вести себя подобно всему остальному ПО, используя типичные для ОС места хранения конфигурации, исполняемых файлов и т.д. Очевидно, что если приложение планируется обновляться средствами обновления ОС, то первый вариант не может быть принят как режим по-умолчанию, т.к. процесс обновления должен проводить обновление вне зависимости от того, является ли приложение "важным" или же нет. Нестандартное внедрение в этом случае остаётся на совести администратора и предполагает, что обслуживание его целиком и полностью выполняет администратор.