O D-Bus não está usando o arquivo magic cookie aqui; está passando as credenciais pelo soquete do domínio UNIX ( SCM_CREDENTIALS ).
O arquivo magic cookie é apenas um dos vários mecanismos de autenticação do D-Bus. O D-Bus implementa uma interface compatível com o SASL (veja RFC4422 ) para suportar uma ampla gama de mecanismos de autenticação. Um desses mecanismos é chamado de autenticação "EXTERNAL" e significa que o próprio canal de transporte deve ser usado para garantir a autenticação. Pelo menos no caso do D-Bus sobre sockets UNIX, este parece ser o primeiro mecanismo de autenticação que é tentado.
Da especificação do D-Bus:
Special credentials-passing nul byte
Immediately after connecting to the server, the client must send a single nul byte. This byte may be accompanied by credentials information on some operating systems that use sendmsg() with SCM_CREDS or SCM_CREDENTIALS to pass credentials over UNIX domain sockets. However, the nul byte must be sent even on other kinds of socket, and even on operating systems that do not require a byte to be sent in order to transmit credentials. The text protocol described in this document begins after the single nul byte. If the first byte received from the client is not a nul byte, the server may disconnect that client.
A nul byte in any context other than the initial byte is an error; the protocol is ASCII-only.
The credentials sent along with the nul byte may be used with the SASL mechanism EXTERNAL.
Se você rastrear uma instância de dbus-daemon , poderá ver que, ao se conectar a ela, ela verifica as credenciais do usuário conectado:
$ 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)=[{"$ 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)=[{"%pre%", 1}], msg_controllen=0, msg_flags=0}, 0) = 1
getsockopt(8, SOL_SOCKET, SO_PEERCRED, {pid=6694, uid=1000, gid=1000}, [12]) = 0
", 1}], msg_controllen=0, msg_flags=0}, 0) = 1
getsockopt(8, SOL_SOCKET, SO_PEERCRED, {pid=6694, uid=1000, gid=1000}, [12]) = 0
Então, responda suas perguntas:
-
O daemon D-Bus está usando seu ID de usuário verificado pelo kernel para verificar sua identidade. Usando
socatpara conexões proxy, você está permitindo que qualquer um se conecte ao daemon D-Bus usando seu UID. -
Se você tentar se conectar diretamente ao soquete de outro UID, o daemon reconhecerá que o UID de conexão não é um UID que deve ter permissão para se conectar. Acredito que o padrão é que somente o próprio UID do daemon é permitido, mas não o verificaram formalmente. Você pode permitir outros usuários: veja os arquivos de configuração em
/etc/dbus-1/e tambémman dbus-daemon. -
Este é o servidor D-Bus que substitui cookies antigos / expirados por novos. De acordo com a seção DBUS_COOKIE_SHA1 da especificação D-Bus, um cookie é armazenado juntamente com o tempo de criação, e o servidor deve excluir os cookies que considera antigos demais. Aparentemente, o tempo de vida "pode ser bastante curto".