И как у тебя в этой хитрожопой конструкции обеспечено, чтобы один зарегистрированный пользователь не мог попортить в тех же таблицах данные другого зарегистрированного пользователя? В предположении, что в коде есть дыра, и он сумел ее, намеренно ли или нечаянно, проэксплойтить.
Что до твоей идеи "как правильно"... Я вижу резкое проседание по производительности и резкий подскок по требованиям к железу. Потому что
- общую базу данных сразу отказать, данные каждого пользователя храним у него.
- поэтому любой запрос, касающийся более чем одного пользователя - шерстить данные каждого, каждый раз с проверкой на уровне ядра, есть ли у данного конкретного тебя право читать данные конкретные данные, т.е. прорва переключений user space - kernel space (пример такого запроса - набор сообщений для модерирования в хронологическом порядке).
- каждый залогиненный пользователь обрабатывается отдельным процессом, т.е. если залогиненный пользователь у тебя не редкость, то много запусков процессов со всеми сопутствующими танцами, включая инициализацию всего и вся.
Сложные иерархический структуры доступа (типа менеджер группы пользователей или членство в группе A по факту членства в группе B) становятся невпихуемыми вообще, потому что в юниксовую модель прав они не лезут.
Сложные workflow, скорее всего, тоже невпихуемы, потому что конфигурация sudo далека от Тьюринг-полной. И вообще, я вижу что-то нездоровое в том, чтобы организовывать workflow через sudoers.
Не говоря уже о том, что дыра в логике, записанной в sudoers, по сути не отличается от дыры в sudo. А ты просто все дыры в безопасности из кода сайта предлагаешь унести в sudoers. Ты хорошо подумал?
Это, кстати, общий принцип. Вот эту сложную логику с правами доступа как к данным, так и к workflow, все равно придется где-то реализовать. Из коробки ОС ее не предоставляет. Из коробки она предоставляет разве что платформу, на которой можно пытаться ее реализовывать. Вместе с возможностью наделать ошибок. И как мы видим выше, так себе платформа-то. Возможностей недостаточно, ресурсов хочет много, возможностей наделать ошибок тоже немало.
В целом, конечно, идея эшелонированной обороны хороша. Но для сайта я не вижу ничего более эффективного, чем запуск движка от нерутового пользователя, у которого нет возможности писать туда, где хотя бы потенциально исполняемый код, плюс TLS для стаффа. Всё хотя бы минимально более защищенное в теории при переходе к практике оказывается как минимум сам-себе-DoS (а это тоже угроза), а скорее всего, и с дополнительными дырами в безопасности. Ну, часто еще можно добавить TLS для всех неанонимов, хотя на нагруженном сайте это тоже сам-себе-DoS.
no subject
Что до твоей идеи "как правильно"... Я вижу резкое проседание по производительности и резкий подскок по требованиям к железу. Потому что
- общую базу данных сразу отказать, данные каждого пользователя храним у него.
- поэтому любой запрос, касающийся более чем одного пользователя - шерстить данные каждого, каждый раз с проверкой на уровне ядра, есть ли у данного конкретного тебя право читать данные конкретные данные, т.е. прорва переключений user space - kernel space (пример такого запроса - набор сообщений для модерирования в хронологическом порядке).
- каждый залогиненный пользователь обрабатывается отдельным процессом, т.е. если залогиненный пользователь у тебя не редкость, то много запусков процессов со всеми сопутствующими танцами, включая инициализацию всего и вся.
Сложные иерархический структуры доступа (типа менеджер группы пользователей или членство в группе A по факту членства в группе B) становятся невпихуемыми вообще, потому что в юниксовую модель прав они не лезут.
Сложные workflow, скорее всего, тоже невпихуемы, потому что конфигурация sudo далека от Тьюринг-полной. И вообще, я вижу что-то нездоровое в том, чтобы организовывать workflow через sudoers.
Не говоря уже о том, что дыра в логике, записанной в sudoers, по сути не отличается от дыры в sudo. А ты просто все дыры в безопасности из кода сайта предлагаешь унести в sudoers. Ты хорошо подумал?
Это, кстати, общий принцип. Вот эту сложную логику с правами доступа как к данным, так и к workflow, все равно придется где-то реализовать. Из коробки ОС ее не предоставляет. Из коробки она предоставляет разве что платформу, на которой можно пытаться ее реализовывать. Вместе с возможностью наделать ошибок. И как мы видим выше, так себе платформа-то. Возможностей недостаточно, ресурсов хочет много, возможностей наделать ошибок тоже немало.
В целом, конечно, идея эшелонированной обороны хороша. Но для сайта я не вижу ничего более эффективного, чем запуск движка от нерутового пользователя, у которого нет возможности писать туда, где хотя бы потенциально исполняемый код, плюс TLS для стаффа. Всё хотя бы минимально более защищенное в теории при переходе к практике оказывается как минимум сам-себе-DoS (а это тоже угроза), а скорее всего, и с дополнительными дырами в безопасности. Ну, часто еще можно добавить TLS для всех неанонимов, хотя на нагруженном сайте это тоже сам-себе-DoS.