Вопросы Теги

Аутентификация и авторизация D-шины

Возможно, это была бы хорошая идея заменить:

# -------- get dataset of filesystem
DATASET=`df -h $1 | grep -v Filesystem | awk '{print $1}'`

со следующим:

# -------- get dataset of filesystem
DATASET=`df -h $1 | awk '{print $1}' | tail -n 1`

Из-за проблем локализации о некоторых установках некоторые дистрибутивы думают, что это - хорошая идея заменить такие вещи в качестве "Файловой системы" с локализованным кулоном, например, "Dateisystem".

13
13.04.2017, 15:13
1 ответ

D-Bus не использует файл Magic Cookie здесь; Это пропускает учетные данные по сокете домена Unix ( SCM_CREDENTIONS ).

Волшебный файл cookie - это только один из нескольких механизмов аутентификации D-шины. D-Bus реализует SASL -Compliant интерфейс (см. RFC4422 ) для поддержки широкого спектра механизмов аутентификации. Один из этих механизмов называется «внешним» аутером, и это означает, что сам транспортный канал должен быть использован для гарантии аутентификации. По крайней мере, в случае D-Bus по сокетам Unix, это, кажется, является первым механизмом аутентификации, который пытается.

Из спецификации D-Bus:

Специальные учетные данные, проходящие в байте Nul

сразу после подключения к серверу, клиент должен отправить один байт Nul. Этот байт может сопровождаться информацией об учетных данных о некоторых операционных системах, которые используют SendMSG () с SCM_CReds или SCM_CREDENTIONS, чтобы пройти учетные данные на доменных сокетах Unix. Однако Nul Byte должен быть отправлен даже на других видах сокета, и даже на операционные системы, которые не требуют отправки байта для передачи учетных данных. Текстовый протокол, описанный в этом документе, начинается после одного байта Nul. Если первый байт, полученный от клиента, не является байтом Nul, сервер может отключить этот клиент.

Нул байт в любом контексте, отличном от первоначального байта, является ошибкой; Протокол - только ASCII.

Учетные данные, отправленные вместе с байтом NUL, могут использоваться с внешним механизмом SASL.

Если вы поправляете экземпляр DBUS-DAEEMON , вы можете увидеть, что при подключении к нему подключается, он проверяет учетные данные соединительного пользователя: 

$ strace dbus-daemon --session --nofork
...
accept4(4, {sa_family=AF_LOCAL, NULL}, [2], SOCK_CLOEXEC) = 8
...
recvmsg(8, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}], msg_controllen=0, msg_flags=0}, 0) = 1
getsockopt(8, SOL_SOCKET, SO_PEERCRED, {pid=6694, uid=1000, gid=1000}, [12]) = 0

так, чтобы ответить на ваши вопросы:

  1. Демон D-Bus использует ваш проверенный ядр идентификатор пользователя для проверки вашей идентификации. Используя SOCAT к прокси-соединениям, вы получаете кому-либо подключиться к демону D-шины с использованием вашего UID.

  2. Если вы пытаетесь напрямую подключиться к разъему с другого UID, демон распознает, что подключение UID не является UID, который должен быть разрешен для подключения. Я считаю, что значение по умолчанию - это то, что разрешено только собственное UID демона, но не подтверждено этого. Вы можете позволить другим пользователям, хотя: см. Файлы конфигурации в / etc / dbus-1 / , а также Человек Дбус-демон .

  3. Это сервер D-Bus, заменяющий старые / просроченные файлы cookie с новыми. Согласно разделу DBUS_COOKIE_SHA1 Секции D-Bus, файл cookie хранится вместе с его временем создания, и сервер должен удалять файлы cookie, которые она решает, слишком стары. Видимо, всю жизнь "может быть довольно короткими".

7
27.01.2020, 19:53

Теги

Похожие вопросы