Во-первых, куда могла бы деться проблема производительности для переключения контекстов, если для защиты ты полагаешься на ОС? В этом раскладе отдельный залогиненный юзер - отдельный процесс, и никак иначе. Здравствуй, задача инициализации каждого такого процесса. Дальше можно искать компромисс между количеством одновременно запущенных процессов и временем на инициализацию вновь запущенного, но проблема уже стоит, и это - поиск ее кое-какого решения.
Во-вторых, должен заметить, что когда брались за первые реализации HTTP-северов, аутентификации в HTTP еще и в проекте не было. Ну, что вменяемых до сих пор никто не поддерживает, да и нету их нифига, это уже как раз исторический вопрос. Пользовались бы HTTP аутентификацией - были бы и поддерживались бы.
qmail я, знаешь ли, ставил. Снес довольно быстро, и знаешь, почему? В его модели невозможно проанализировать содержимое письма на этапе SMTP-диалога. В результате не существует корректного работоспособного способа оповестить отправителя о том, что мы отказываемся принять это письмо на основании анализа его содержания. Ну, там и других тараканов хватает. Логика анализа служебной информации у него тоже, мягко говоря, не на высоте. Короче, пока на него реальных задач не вешают, он быстрый и секьюрный.
А разделение ролей по задачам как у qmail (именно как у qmail, а не как у твоей идеи) - ну, так его любой современный движок умеет. Вот рут, от него работает только accept(2) на 80 порту, вот владелец кода, который апгрейдит код сайта, а вот пользователь, от которого этот код выполняется. К сожалению, не то чтобы прям вот все стандартные инструкции заточены под разделение второго и третьего, но уже многие, чесслово. (Тут есть засада - не всегда у разработчика кода сайта есть два логина туда, где он этот код тестирует. В результате он вынужден разрабатывать, совместив этих юзеров.)
Про твою идею я тебе рассказываю примерно то же самое. Что годится она для достаточно узкого класса задач, далеко не покрывающего реальные потребности веб-сервисов. В нем она секьюрная, хотя далеко не быстрая. На глаз - практически применима для сайта с примитивным workflow и частотой запросов единицы в минуту. Ну, малые десятки на непродолжительном пике. Практически - это значит, что код, реализующий необходимую функциональность сайта, все же будет своевременно написан. Теоретически можно сделать лучше, но практически никто этого не потянет.
И кстати, рута-то она реально требует. И далеко не только для того, чтобы занять 80-й порт. Те же описываемые тобой движки работают от одного юзера, но не от рута, как ты тут пишешь. А при нормальном контроле за разработчиками - и не от владельца кода. А твоя идея требует использования рутовых полномочий движком. В полный рост и со сложной логикой. Упс... Дополнительный вектор атаки... Безопасность, говоришь...
Да, конечно, если это выделенная машина под сервер, то возможность испортить любые данные в базе с точки зрения работоспособности сервиса мало отличается от возможности испортить вообще что угодно в системе. А вот с точки зрения восстановления испорченного - ой, отличается... Потому что хотя бы бэкапы взломщик тронуть не сможет - прав не хватит. А при грамотном подходе - и логи тоже.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2016-Feb-22, Monday 15:59 (UTC)Во-первых, куда могла бы деться проблема производительности для переключения контекстов, если для защиты ты полагаешься на ОС? В этом раскладе отдельный залогиненный юзер - отдельный процесс, и никак иначе. Здравствуй, задача инициализации каждого такого процесса. Дальше можно искать компромисс между количеством одновременно запущенных процессов и временем на инициализацию вновь запущенного, но проблема уже стоит, и это - поиск ее кое-какого решения.
Во-вторых, должен заметить, что когда брались за первые реализации HTTP-северов, аутентификации в HTTP еще и в проекте не было. Ну, что вменяемых до сих пор никто не поддерживает, да и нету их нифига, это уже как раз исторический вопрос. Пользовались бы HTTP аутентификацией - были бы и поддерживались бы.
qmail я, знаешь ли, ставил. Снес довольно быстро, и знаешь, почему? В его модели невозможно проанализировать содержимое письма на этапе SMTP-диалога. В результате не существует корректного работоспособного способа оповестить отправителя о том, что мы отказываемся принять это письмо на основании анализа его содержания. Ну, там и других тараканов хватает. Логика анализа служебной информации у него тоже, мягко говоря, не на высоте. Короче, пока на него реальных задач не вешают, он быстрый и секьюрный.
А разделение ролей по задачам как у qmail (именно как у qmail, а не как у твоей идеи) - ну, так его любой современный движок умеет. Вот рут, от него работает только accept(2) на 80 порту, вот владелец кода, который апгрейдит код сайта, а вот пользователь, от которого этот код выполняется. К сожалению, не то чтобы прям вот все стандартные инструкции заточены под разделение второго и третьего, но уже многие, чесслово. (Тут есть засада - не всегда у разработчика кода сайта есть два логина туда, где он этот код тестирует. В результате он вынужден разрабатывать, совместив этих юзеров.)
Про твою идею я тебе рассказываю примерно то же самое. Что годится она для достаточно узкого класса задач, далеко не покрывающего реальные потребности веб-сервисов. В нем она секьюрная, хотя далеко не быстрая. На глаз - практически применима для сайта с примитивным workflow и частотой запросов единицы в минуту. Ну, малые десятки на непродолжительном пике. Практически - это значит, что код, реализующий необходимую функциональность сайта, все же будет своевременно написан. Теоретически можно сделать лучше, но практически никто этого не потянет.
И кстати, рута-то она реально требует. И далеко не только для того, чтобы занять 80-й порт. Те же описываемые тобой движки работают от одного юзера, но не от рута, как ты тут пишешь. А при нормальном контроле за разработчиками - и не от владельца кода. А твоя идея требует использования рутовых полномочий движком. В полный рост и со сложной логикой. Упс... Дополнительный вектор атаки... Безопасность, говоришь...
Да, конечно, если это выделенная машина под сервер, то возможность испортить любые данные в базе с точки зрения работоспособности сервиса мало отличается от возможности испортить вообще что угодно в системе. А вот с точки зрения восстановления испорченного - ой, отличается... Потому что хотя бы бэкапы взломщик тронуть не сможет - прав не хватит. А при грамотном подходе - и логи тоже.