scm_rights - посылаем дескрипторы почтой

Оригинал https://t.me/bits_and_bicycles/18

Всё это время я тут задвигал про uid'ы и gid'ы. Это неплохая система доступов, позволяющая делать комплексные вещи.

Но бывает, твоя задача не решается в рамках такой системы. Ну вот не лезет и всё тут.

Допустим, тебе надо разделить accept соединения и его обработку. Потому что работа твоего сервера с capability CAP_NET_BIND_SERVICE – принимать соединения. Потому что работать же с этими соединениями можно хоть из под nobody. Потому что тебе хочется как-то понизить права.

Да, ты можешь форкнуться и понизить нового себя в правах. Но наследование дескриптора произойдёт только в момент форка. Так что форкаться тебе придётся на каждое соединение. Очевидно, что быстро работать это не может.

Да, ты можешь поднять внутри своего основного процесса колхозный RPC и перекладывать через него данные. Просто доставать данные из одной трубы, чтобы переложить в другую.

Но зачем всё это, если ты можешь отправлять fd'шки почтой по unix-сокетам.

Буквально, по unix-сокетам можно отправить почти любой открытый дескриптор соседу. Фича называется SCM_RIGHTS, часть socket ancillary data. И это не что-то новое. Фича есть в #POSIX'е минимум 15 лет.

Используется это добро, например, в DRI Xserver'а и в wayland'е, чтобы отдать пользователю преднастроеный дескриптор /dev/video. В nodejs (через поддержку в libuv) используется для ipc и балансировки cluster'ом.

Есть ещё SO_PEERCRED, чтобы узнать uid/gid процесса с другой стороны сокета, и SCM_CREDENTIALS, чтобы отправить любые uid/gid. Которые проверятся ядром, а его не обманешь. Такая бесплатная авторизация в локальных демонах. Зачем при такой фиче нужен kostilique .Xauthority для меня загадка.