Я забрал доступ, а человек всё ещё внутри: сеанс и право доступа это не одно и то же
Вы сняли право, даже отключили учётную запись, а человек всё ещё что-то может. Ничего не сломалось: забрать доступ и завершить сеанс это два разных действия.
AtlasPVE ·
Эта статья отвечает на
- proxmox удалил пользователя а он всё ещё входит
- proxmox снял права а доступ остался
- proxmox постоянно выкидывает из сессии
- сколько длится сеанс proxmox
- proxmox отозвать api токен
Вы сняли право у пользователя. Возможно, отключили учётную запись целиком. Потом замечаете, что этот человек всё ещё может что-то делать.
Ничего не сломалось. Вход и наличие права это два разных момента, и между ними есть зазор.
Вход происходит один раз, право спрашивается каждый раз
При входе система выдаёт вам билет. Билет говорит: этот человек подтвердил, кто он, и билет действителен до такого-то времени.
Право это отдельный вопрос, который задаётся заново при каждом запросе. Но на практике многие системы ради скорости берут в момент входа копию карты прав и какое-то время пользуются этой копией.
Отсюда возникают две задержки.
Первая: когда вы снимаете право, открытый сеанс может продолжать нести ту копию. Изменение доходит до него только при обновлении сеанса.
Вторая, и более важная: удаление или отключение пользователя не рвёт билет, который у него на руках. Билет самодостаточен и остаётся действительным до истечения срока.
Правило: забрать доступ это не то же самое, что завершить сеанс
Это два разных действия, и сделав только первое, вы оставляете за собой открытое окно.
Окно не бесконечно; билет не действует сутки. Но и не равно нулю, а в срочной ситуации ответ «скоро закроется» недостаточен.
Когда кто-то уходит или пароль под подозрением
Сделайте три вещи по порядку.
Снимите право. Отключите и учётную запись, если это оправдано.
Смените пароль. Это закрывает путь получить свежий билет взамен имеющегося. Одно лишь снятие права этого не делает.
Удалите токены доступа отдельно. Это самый пропускаемый шаг. Токен не сеанс: сам по себе он не истекает, он живёт, пока вы его не удалите. Смена пароля пользователя не делает его токены недействительными. Удаляя пользователя, отдельно проверьте, что стало с его токенами.
И закроем одно заблуждение: двухфакторная проверка здесь не поможет. Она охраняет момент входа. К уже открытому сеансу она отношения не имеет.
Обратная сторона: почему меня постоянно выкидывает
Это другая грань того же механизма.
У билета ограниченный срок жизни, и интерфейс регулярно продлевает его, пока вы на вкладке. Закройте вкладку и вернитесь через несколько часов: продления не было, билет мёртв, и у вас просят войти заново. Это не поломка.
Вторая, менее известная причина интереснее: часы машины. Билет несёт отметку времени. Если часы сервера уходят, только что выданный билет может выглядеть пришедшим из будущего или давно истёкшим. Симптом сбивает с толку: пароль верный, вход как будто принят, и сразу после этого сеанс падает. Искать проблему часов на стороне входа никому не приходит в голову, но поищите.
Что делает Atlas
В Atlas файл cookie, уходящий в браузер, не является настоящим билетом. Браузер несёт лишь бессмысленный случайный идентификатор; сам билет остаётся на сервере.
Разница вполне конкретная: даже если уязвимость браузера прочитает cookie, она не получит сам билет, а значит, не сможет унести его в другое место и воспользоваться им там. Единственное, что она сможет, это действовать из того же браузера, пока жив тот сеанс. Это не нулевой риск, но он сужает охват угрозы.
Открытые сеансы записываются на диск, поэтому при обновлении продукта никого не выбрасывает. Запись намеренно делается в один шаг: если бы файл остался записанным наполовину, то, пусть читающая сторона это и терпит, упали бы все открытые сеансы.
По-настоящему стоит рассказать о недостатке, найденном здесь измерением.
Просроченные записи сеансов очищались только из памяти, но не из файла. Была осмотрена работающая машина: в файле лежали пять просроченных записей, и внутри каждой был билет. Они пролежали бы там до следующего входа, потому что в этот файл больше ничто никогда не писало.
Замысел кода уже состоял в том, чтобы их не хранить. Не хватало лишь шага записи.
Урок годится всякому, кто пишет код безопасности: у забывания два места. Удалённое из памяти не удалено с диска, и из двух дольше всегда живёт то, что на диске. Когда вы решаете, что нечто не должно храниться, второй вопрос всегда один и тот же: а где оно хранится?
Источники
Собственная документация Proxmox. На английском, и последнее слово в этом вопросе за ней.