D-Bus (Desktop Bus)

D-Bus 시스템/세션 버스(Bus) 아키텍처, 메시지 모델(Method Call/Signal/Property), 버스 이름과 객체 경로 체계, 타입 시스템, 서비스 활성화, 보안 모델(Policy/Polkit), 커널과의 관계(AF_UNIX/kdbus), 주요 서비스, 도구(busctl/dbus-monitor), 프로그래밍 인터페이스(sd-bus/GIO), 성능과 대안 분석을 종합 정리

D-Bus가 필요한 이유(Why D-Bus?)

D-Bus는 2002년 freedesktop.org 프로젝트에서 시작되었으며, 리눅스 데스크톱과 시스템 서비스들이 공통으로 사용할 수 있는 표준 IPC 메커니즘을 제공하기 위해 만들어졌습니다.

D-Bus 이전의 IPC 문제

D-Bus가 없던 시절, 프로세스끼리 통신하려면 각자 다른 방법을 직접 구현해야 했습니다.

D-Bus가 해결하는 문제

D-Bus 없이 하면 어떻게 될까?

예를 들어 네트워크 연결 상태를 확인하는 프로그램을 만든다고 가정합니다.

D-Bus 아키텍처(Architecture)

D-Bus는 중앙 집중형 메시지 버스 구조를 사용합니다. 클라이언트(Client)와 서비스(Service)가 직접 통신하지 않고, 중간에 위치한 버스 데몬(Bus Daemon)이 메시지를 라우팅(Routing)합니다. 이 구조 덕분에 서비스 발견(Service Discovery), 활성화(Activation), 접근 제어(Access Control)를 한 곳에서 관리할 수 있습니다.

시스템 버스와 세션 버스

리눅스 시스템에서는 항상 두 종류의 버스가 동작합니다.

버스 데몬 구현체

D-Bus 사양(Specification)과 버스 데몬 구현은 분리되어 있습니다. 주요 구현체는 두 가지입니다.

두 구현체 모두 같은 D-Bus 프로토콜(Protocol)을 사용하므로, 클라이언트 코드는 어떤 데몬이 동작하든 동일하게 작동합니다.

dbus-broker 내부 구조

dbus-broker는 단일 프로세스인 dbus-daemon과 달리, 역할을 분리한 다중 컴포넌트(Multi-component) 구조를 사용합니다.

소켓 활성화(Socket Activation)

현대 시스템에서 dbus-daemon/dbus-broker는 systemd 소켓 활성화(Socket Activation)로 시작됩니다. systemd가 먼저 소켓을 열어 두고, 첫 연결이 들어오면 버스 데몬을 시작합니다.

# /usr/lib/systemd/system/dbus.socket
[Unit]
Description=D-Bus System Message Bus Socket

[Socket]
ListenStream=/run/dbus/system_bus_socket
SocketMode=0666

[Install]
WantedBy=sockets.target

# /usr/lib/systemd/system/dbus-broker.service (Fedora/RHEL)
[Unit]
Description=D-Bus System Message Bus
Requires=dbus.socket

[Service]
Type=notify
ExecStart=/usr/bin/dbus-broker-launch --scope system
NotifyAccess=main
WatchdogSec=3min

이 구조 덕분에 부팅 초기에 D-Bus 소켓이 준비되어 있고, 다른 서비스들이 D-Bus 연결을 시도하면 그때 버스 데몬이 시작됩니다. 이는 부팅 순서 의존성(Boot Order Dependency) 문제를 해결합니다.

연결 수립 과정(Connection Lifecycle)

프로세스가 D-Bus에 연결할 때는 단순히 소켓에 접속하는 것으로 끝나지 않습니다. 인증(Authentication)과 핸드셰이크(Handshake) 과정을 거쳐야 합니다.

1. 소켓 연결: 클라이언트가 /run/dbus/system_bus_socket(시스템 버스) 또는 $XDG_RUNTIME_DIR/bus(세션 버스)에 TCP 연결이 아닌 AF_UNIX(Unix Domain Socket)으로 접속합니다.
2. 인증(Authentication): D-Bus는 SASL(Simple Authentication and Security Layer) 프레임워크를 사용합니다. 리눅스에서는 EXTERNAL 메커니즘으로 커널이 보장하는 UID(User ID) 정보를 전달합니다.

   # 클라이언트 → 버스 데몬 (NUL 바이트로 시작, 이후 ASCII 텍스트)
   \0AUTH EXTERNAL 31303030  # "1000"의 16진수 ASCII — 현재 프로세스의 UID
   # 버스 데몬 → 클라이언트
   OK 1234567890abcdef         # 인증 성공, 서버 GUID(Globally Unique Identifier)

3. 협상 시작(BEGIN): 인증 완료 후 클라이언트가 BEGIN을 보내면 D-Bus 프로토콜 메시지 교환이 시작됩니다.
4. HELLO 메시지: 클라이언트가 org.freedesktop.DBus의 Hello() 메서드를 호출합니다. 버스 데몬은 이 연결에 고유 이름(Unique Name)을 할당하여 응답합니다.

   # strace로 busctl 실행 시 HELLO 교환 확인 (첫 write syscall)
   strace -e trace=write busctl list --system 2>&1 | head -5
   # write(4, "l\1\0\1..."  ← 'l'=리틀엔디언, 메시지 타입=1(METHOD_CALL)
   #   HELLO 메시지를 버스 데몬으로 전송

5. 고유 이름 수신: 버스 데몬이 :1.숫자 형식의 고유 이름을 클라이언트에게 반환합니다. 이후 모든 메시지의 발신자(Sender) 필드에 이 이름이 기록됩니다.
6. 잘 알려진 이름 등록 (서비스인 경우): 서비스라면 추가로 RequestName("org.example.MyService")를 호출하여 사람이 읽을 수 있는 이름을 등록합니다.

메시지 라우팅 과정

클라이언트가 메서드를 호출하면 다음과 같은 과정을 거칩니다.

1. 클라이언트가 메서드 호출 메시지를 버스 데몬의 소켓으로 전송합니다.
2. 버스 데몬이 메시지의 목적지(Destination) 필드를 확인하여 해당 서비스를 찾습니다.
3. 서비스가 현재 실행 중이 아니면, 서비스 활성화(Service Activation)를 통해 서비스를 시작합니다.
4. 버스 데몬이 보안 정책(Security Policy)을 검사하여 호출이 허용되는지 확인합니다.
5. 허용되면 메시지를 목적지 서비스의 소켓으로 전달합니다.
6. 서비스가 처리 후 응답 메시지(Method Return) 또는 오류 메시지(Error)를 버스 데몬으로 보내고, 데몬이 이를 원래 호출자에게 전달합니다.

메시지 모델(Message Model)

D-Bus의 모든 통신은 메시지(Message) 단위로 이루어집니다. 메시지는 헤더(Header)와 본문(Body)으로 구성되며, 헤더에는 메시지 타입과 라우팅 정보가, 본문에는 실제 데이터가 담깁니다.

메시지 타입

메시지 헤더 필드

와이어 포맷(Wire Format)

D-Bus 메시지는 네트워크 바이트 순서(Byte Order)가 아닌, 발신자의 엔디언(Endianness)을 따릅니다. 수신자는 첫 바이트로 엔디언을 판별합니다.

메시지 플래그(Message Flags)

# NO_REPLY_EXPECTED 플래그로 호출 (응답 대기 없음)
busctl call --expect-reply=no org.freedesktop.systemd1 \
  /org/freedesktop/systemd1 \
  org.freedesktop.systemd1.Manager Reload

# NO_AUTO_START 플래그로 호출 (자동 활성화 비활성화)
busctl call --auto-start=no org.example.Optional \
  /org/example/Optional org.example.Optional Ping

프로퍼티(Property) 접근

D-Bus 서비스의 상태 값은 프로퍼티(Property)로 노출됩니다. 프로퍼티는 실제로 org.freedesktop.DBus.Properties 인터페이스의 메서드 호출로 구현됩니다.

# 특정 프로퍼티 읽기
busctl get-property org.freedesktop.NetworkManager \
  /org/freedesktop/NetworkManager \
  org.freedesktop.NetworkManager State

# 모든 프로퍼티 나열
busctl introspect org.freedesktop.NetworkManager \
  /org/freedesktop/NetworkManager \
  org.freedesktop.NetworkManager

# 프로퍼티 변경 시그널 구독
dbus-monitor --system "type='signal',interface='org.freedesktop.DBus.Properties',member='PropertiesChanged'"

프로퍼티가 변경되면 서비스는 PropertiesChanged 시그널을 발생시킵니다. 이 시그널은 변경된 프로퍼티 이름과 새 값, 그리고 값이 비싸서 시그널에 포함하지 않은(invalidated) 프로퍼티 목록을 전달합니다.

버스 이름과 객체 경로(Bus Names & Object Paths)

버스 이름의 두 가지 유형

하나의 연결(Connection)이 여러 개의 잘 알려진 이름을 소유할 수 있고, 잘 알려진 이름의 소유권(Ownership)은 큐(Queue)로 관리됩니다. 현재 소유자가 해제하면 큐의 다음 요청자가 자동으로 소유자가 됩니다.

이름 소유권 관리

RequestName 메서드로 잘 알려진 이름을 요청할 때 동작 플래그(Flag)를 지정할 수 있습니다.

# 이름 소유권 확인
busctl list --system | grep NetworkManager
# org.freedesktop.NetworkManager  1234  NetworkManager  root  :1.15  ...

# 이름 소유자 변경 모니터링
dbus-monitor --system "type='signal',member='NameOwnerChanged'"
# signal sender=org.freedesktop.DBus -> dest=(null)
#   member=NameOwnerChanged
#   string "org.freedesktop.NetworkManager"
#   string ":1.15"    ← 이전 소유자
#   string ":1.203"   ← 새 소유자 (서비스 재시작 시)

# 특정 이름의 소유자 PID 확인
busctl status org.freedesktop.NetworkManager

NameOwnerChanged 시그널은 서비스의 생명주기(Lifecycle)를 추적하는 핵심 메커니즘입니다. 이전 소유자가 빈 문자열이면 서비스가 새로 시작된 것이고, 새 소유자가 빈 문자열이면 서비스가 종료된 것입니다.

객체 경로(Object Path)

D-Bus 서비스 내부에서 특정 기능 단위를 식별하는 경로입니다. 파일 시스템 경로처럼 /로 구분된 계층 구조를 사용합니다.

이름 규칙 요약

인터페이스(Interface)와 인트로스펙션(Introspection)

인터페이스(Interface)는 하나의 객체(Object)가 제공하는 메서드(Method), 시그널(Signal), 프로퍼티(Property)의 집합입니다. 하나의 객체가 여러 인터페이스를 동시에 구현할 수 있습니다.

표준 인터페이스

모든 D-Bus 객체가 반드시(또는 관례적으로) 구현하는 표준 인터페이스가 있습니다.

인트로스펙션 XML

Introspect() 메서드를 호출하면 객체의 전체 API 구조를 XML로 받을 수 있습니다.

# busctl로 인트로스펙션 실행
busctl introspect org.freedesktop.systemd1 /org/freedesktop/systemd1

<!-- Introspect() 반환 XML 예시 (요약) -->
<node name="/org/freedesktop/systemd1">
  <interface name="org.freedesktop.systemd1.Manager">
    <method name="StartUnit">
      <arg name="name" type="s" direction="in"/>
      <arg name="mode" type="s" direction="in"/>
      <arg name="job" type="o" direction="out"/>
    </method>
    <signal name="UnitNew">
      <arg name="id" type="s"/>
      <arg name="unit" type="o"/>
    </signal>
    <property name="Version" type="s" access="read"/>
  </interface>
  <interface name="org.freedesktop.DBus.Properties">
    <!-- Get, Set, GetAll, PropertiesChanged -->
  </interface>
  <node name="unit"/>
  <node name="job"/>
</node>

busctl introspect 출력 읽기

busctl introspect는 인트로스펙션 결과를 테이블 형태로 보여줍니다.

$ busctl introspect org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager
NAME                       TYPE      SIGNATURE  RESULT/VALUE  FLAGS
.GetUnit                   method    s          o             -
.ListUnits                 method    -          a(ssssssouso) -
.Reload                    method    -          -             -
.StartUnit                 method    ss         o             -
.StopUnit                  method    ss         o             -
.UnitNew                   signal    so         -             -
.UnitRemoved               signal    so         -             -
.Version                   property  s          "256"         const
.NNames                    property  u          412           emits-change

인터페이스 설계 패턴

D-Bus 서비스를 설계할 때 반복적으로 사용되는 패턴이 있습니다.

어노테이션(Annotation) 태그

인트로스펙션 XML에서 <annotation> 요소는 멤버에 대한 메타데이터(Metadata)를 제공합니다.

gdbus-codegen 코드 생성

GLib 기반 프로젝트에서는 gdbus-codegen으로 인트로스펙션 XML에서 C 바인딩(Binding)을 자동 생성할 수 있습니다.

# 1. 서비스에서 인트로스펙션 XML 추출
gdbus introspect --system --dest org.freedesktop.UPower \
  --object-path /org/freedesktop/UPower --xml > upower.xml

# 2. C 코드 생성 (헤더 + 소스)
gdbus-codegen --interface-prefix org.freedesktop.UPower \
  --generate-c-code upower-generated \
  --c-namespace UPower \
  upower.xml

# 3. 생성된 파일: upower-generated.h, upower-generated.c
# 프록시(Proxy) 객체로 메서드 호출:
#   UPowerDevice *proxy = upower_device_proxy_new_for_bus_sync(...);
#   gdouble percentage = upower_device_get_percentage(proxy);

D-Bus 타입 시스템(Type System)

D-Bus는 자체 타입 시스템(Type System)을 가지고 있으며, 메시지의 본문 데이터는 이 타입 시스템에 따라 직렬화(Serialization)됩니다. 각 타입은 한 글자의 시그니처 문자(Signature Character)로 표현됩니다.

기본 타입(Basic Types)

컨테이너(Container) 타입(Container Types)

시그니처 읽기 예제

# busctl에서 시그니처 확인
busctl call org.freedesktop.systemd1 \
  /org/freedesktop/systemd1 \
  org.freedesktop.systemd1.Manager \
  ListUnits
# 반환 시그니처: a(ssssssouso) — 유닛 정보 구조체의 배열

마샬링 정렬 규칙(Marshalling Alignment)

D-Bus 와이어 포맷에서 각 타입은 자연 정렬(Natural Alignment)을 따릅니다. 이전 필드 끝부터 다음 필드 시작까지 필요한 만큼 패딩 바이트(0x00)가 삽입됩니다.

Variant 중첩과 제한

# 복합 Variant 값 설정 (a{sv} 사전 안에 다양한 타입)
busctl call --user com.example.Config \
  /com/example/Config com.example.Config SetOptions \
  a{sv} 3 \
    "timeout" v u 30 \
    "name" v s "production" \
    "tags" v as 2 "web" "api"
# timeout → UINT32(30), name → STRING, tags → STRING 배열

서비스 활성화(Service Activation)

D-Bus의 서비스 활성화(Service Activation)는 서비스가 실행되지 않은 상태에서 클라이언트가 해당 서비스를 호출하면 자동으로 서비스를 시작하는 메커니즘입니다.

서비스 파일(.service)

서비스 활성화를 위해서는 .service 파일이 필요합니다.

# /usr/share/dbus-1/system-services/org.freedesktop.NetworkManager.service
[D-BUS Service]
Name=org.freedesktop.NetworkManager
Exec=/usr/sbin/NetworkManager --no-daemon
User=root
SystemdService=NetworkManager.service

활성화 시퀀스

클라이언트 입장에서는 서비스가 이미 실행 중이든 활성화를 통해 시작되든 동일하게 동작합니다. 단, 서비스 시작에 시간이 걸리므로 첫 호출의 응답 시간이 길어질 수 있습니다. busctl --auto-start=no로 자동 활성화를 비활성화할 수 있습니다.

systemd 유닛 타입: Type=dbus vs Type=notify

D-Bus 서비스의 systemd 유닛을 작성할 때, 준비 완료(Readiness) 신호 방식을 선택해야 합니다.

# Type=dbus 예시 — D-Bus 이름 등록 시점에 준비 완료
[Service]
Type=dbus
BusName=org.freedesktop.NetworkManager
ExecStart=/usr/sbin/NetworkManager --no-daemon

# Type=notify 예시 — sd_notify("READY=1") 호출 시점에 준비 완료
[Service]
Type=notify
ExecStart=/usr/lib/bluetooth/bluetoothd --nodetach
NotifyAccess=main

자동 시작 제어

D-Bus 서비스 파일에 SystemdService=가 있으면 dbus-daemon은 직접 프로세스를 시작하지 않고 systemd에 위임합니다. 이를 통해 LimitNOFILE=, MemoryMax= 같은 리소스 제한(Resource Limit)과 journalctl 로그 통합을 활용할 수 있습니다.

자동 활성화를 원하지 않는 서비스는 .service 파일을 제공하지 않거나, 클라이언트에서 NO_AUTO_START 플래그를 설정합니다.

보안 모델(Security Model)

D-Bus의 보안은 여러 계층(Layer)으로 구성되어, 각 단계에서 접근을 제어합니다.

D-Bus 정책 파일

시스템 버스의 정책 파일은 /usr/share/dbus-1/system.d/ 또는 /etc/dbus-1/system.d/에 위치합니다. 서비스별로 하나의 .conf 파일을 가집니다.

정책 규칙 속성

<allow>와 <deny> 요소에서 사용할 수 있는 속성입니다. 여러 속성을 조합하면 AND 조건으로 동작합니다.

<!-- /usr/share/dbus-1/system.d/org.freedesktop.NetworkManager.conf -->
<busconfig>
  <!-- NetworkManager가 시스템 버스에서 이름을 소유하도록 허용 -->
  <policy user="root">
    <allow own="org.freedesktop.NetworkManager"/>
  </policy>

  <!-- 모든 사용자가 인트로스펙션과 프로퍼티 읽기 가능 -->
  <policy context="default">
    <allow send_destination="org.freedesktop.NetworkManager"
           send_interface="org.freedesktop.DBus.Introspectable"/>
    <allow send_destination="org.freedesktop.NetworkManager"
           send_interface="org.freedesktop.DBus.Properties"/>
  </policy>

  <!-- netdev 그룹 사용자만 설정 변경 가능 -->
  <policy group="netdev">
    <allow send_destination="org.freedesktop.NetworkManager"
           send_interface="org.freedesktop.NetworkManager"/>
  </policy>
</busconfig>

Polkit 통합

D-Bus 정책이 "이 사용자가 이 메서드를 호출할 수 있는가"를 결정하는 1차 관문이라면, Polkit은 "이 작업에 관리자 인증이 필요한가"를 결정하는 2차 관문입니다.

서비스가 Polkit을 사용하는 흐름:

1. 클라이언트가 D-Bus 메서드를 호출합니다.
2. 서비스가 메서드 핸들러(Handler)에서 polkit_authority_check_authorization()을 호출합니다.
3. Polkit이 .policy 파일과 .rules 파일을 검사하여 허용/거부/인증 요구를 결정합니다.
4. 인증이 필요하면 Polkit 에이전트(Agent)가 사용자에게 비밀번호 입력 대화상자를 표시합니다.
5. 인증 성공 시 서비스가 요청을 처리합니다.

# Polkit 액션 목록 확인
pkaction | grep NetworkManager

# 특정 액션의 상세 정보
pkaction --verbose --action-id org.freedesktop.NetworkManager.settings.modify.system

Polkit .policy 파일

.policy 파일은 /usr/share/polkit-1/actions/에 위치하며, 액션(Action)별 기본 권한을 정의합니다.

<!-- /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy (요약) -->
<?xml version="1.0" encoding="UTF-8"?>
<policyconfig>
  <action id="org.freedesktop.NetworkManager.settings.modify.system">
    <description>시스템 네트워크 설정 변경</description>
    <message>시스템 네트워크 설정을 변경하려면 인증이 필요합니다</message>
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
  </action>
</policyconfig>

Polkit .rules 파일

.rules 파일은 /etc/polkit-1/rules.d/에 JavaScript로 작성합니다. .policy의 기본값을 조건부로 오버라이드(Override)합니다.

// /etc/polkit-1/rules.d/10-networkmanager.rules
// wheel 그룹 사용자에게 NetworkManager 설정 변경을 비밀번호 없이 허용
polkit.addRule(function(action, subject) {
    if (action.id === "org.freedesktop.NetworkManager.settings.modify.system" &&
        subject.isInGroup("wheel")) {
        return polkit.Result.YES;
    }
});

강제 접근 제어(MAC) 통합

SELinux가 활성화된 시스템에서는 D-Bus 메시지 전송·수신에 대해 추가 보안 컨텍스트(Security Context) 검사가 이루어집니다. dbus { send_msg receive_msg } 권한 클래스로 제어합니다.

# SELinux D-Bus 거부 로그 확인
ausearch -m AVC --comm dbus-daemon --recent
# type=AVC msg=audit(...): avc:  denied  { send_msg } for
#   scontext=system_u:system_r:httpd_t:s0
#   tcontext=system_u:system_r:NetworkManager_t:s0
#   tclass=dbus

AppArmor 환경(Ubuntu 등)에서는 D-Bus 프로파일(Profile)에서 dbus send와 dbus receive 규칙으로 특정 버스 이름·인터페이스·멤버에 대한 접근을 제어합니다.

# AppArmor D-Bus 프로파일 예시 (/etc/apparmor.d/usr.sbin.NetworkManager)
# 시스템 버스에서 이름 바인딩 허용
dbus bind bus=system name=org.freedesktop.NetworkManager,

# systemd로부터의 메서드 호출 수신 허용
dbus receive bus=system
     peer=(label=/usr/lib/systemd/systemd),

# 모든 클라이언트에 시그널 송신 허용
dbus send bus=system
     interface=org.freedesktop.NetworkManager
     member={StateChanged,PropertiesChanged},

# Properties 인터페이스 읽기 허용
dbus send bus=system
     interface=org.freedesktop.DBus.Properties
     member={Get,GetAll},

흔한 D-Bus 보안 실수

커널과의 관계(Kernel Relationship)

D-Bus는 사용자 공간(User Space)(Userspace) 프로토콜이지만, 그 기반은 커널이 제공하는 기능에 깊이 의존합니다.

AF_UNIX 소켓 전송

D-Bus의 기본 전송 계층(Transport Layer)은 AF_UNIX 소켓(SOCK_STREAM)입니다. 커널이 제공하는 다음 기능을 활용합니다:

SCM_CREDENTIALS 상세

D-Bus 데몬이 클라이언트를 식별하는 핵심 메커니즘은 SO_PEERCRED 소켓 옵션과 SCM_CREDENTIALS 보조 메시지(Ancillary Message)입니다.

/* SO_PEERCRED로 연결된 피어의 자격 증명 조회 */
#include <sys/socket.h>

struct ucred cred;
socklen_t len = sizeof(cred);

if (getsockopt(client_fd, SOL_SOCKET, SO_PEERCRED, &cred, &len) == 0) {
    printf("PID=%d, UID=%d, GID=%d\n", cred.pid, cred.uid, cred.gid);
    /* dbus-daemon은 이 정보로 정책의 user=, group= 규칙을 평가 */
}

/* SCM_RIGHTS로 파일 디스크립터 전달 (D-Bus UNIX_FD 타입의 기반) */
struct msghdr msg = { 0 };
struct cmsghdr *cmsg;
char cmsgbuf[CMSG_SPACE(sizeof(int))];

msg.msg_control = cmsgbuf;
msg.msg_controllen = sizeof(cmsgbuf);

cmsg = CMSG_FIRSTHDR(&msg);
cmsg->cmsg_level = SOL_SOCKET;
cmsg->cmsg_type = SCM_RIGHTS;
cmsg->cmsg_len = CMSG_LEN(sizeof(int));
*((int *)CMSG_DATA(cmsg)) = file_fd;  /* 전달할 fd */

sendmsg(socket_fd, &msg, 0);
/* 수신 측에서 recvmsg()로 fd를 받음 — 커널이 fd 테이블 복제 수행 */

strace로 D-Bus 통신 관찰

# dbus-daemon의 소켓 I/O 추적
$ strace -e trace=sendmsg,recvmsg -p $(pidof dbus-daemon) 2>&1 | head -8

recvmsg(12, {
  msg_iov=[{iov_base="l\1\0\1"...  ← 'l'=리틀엔디언, 1=METHOD_CALL
            iov_len=184}],
  msg_control=[{cmsg_level=SOL_SOCKET,
                cmsg_type=SCM_CREDENTIALS,  ← 커널이 자동 첨부
                cmsg_data={pid=3847, uid=1000, gid=1000}}]
}, 0) = 184

sendmsg(15, {  ← fd 15 = 목적지 서비스의 소켓
  msg_iov=[{iov_base="l\1\0\1"...
            iov_len=184}]
}, 0) = 184

cgroup 통합

dbus-broker는 커널의 cgroup(Control Group) 정보를 추가적인 발신자 식별 수단으로 활용합니다. /proc/PID/cgroup을 읽어 발신 프로세스가 속한 systemd 슬라이스(Slice)와 서비스 유닛(Unit)을 파악할 수 있으며, 이를 통해 PID보다 더 안정적인 프로세스 식별이 가능합니다. PID는 재사용(Reuse)될 수 있지만, cgroup 경로는 서비스 수명 동안 유일합니다.

kdbus 역사

kdbus는 D-Bus를 커널 내부에 구현하려는 시도였습니다. 2013년부터 2015년까지 Greg Kroah-Hartman이 주도하여 커널 메인라인(Mainline) 합류를 시도했으나, 여러 이유로 거부되었습니다:

• 보안 공격 표면(Attack Surface) 증가: IPC 프로토콜 전체를 커널에 넣으면 취약점(Vulnerability) 위험이 커짐
• 정책 로직의 커널 이동: D-Bus 정책은 복잡한 XML 규칙인데, 이를 커널에서 처리하는 것은 부적절
• 사용자 공간 대안의 충분한 성능: dbus-broker가 커널 기반 접근 없이도 충분한 성능을 달성

kdbus의 유산으로 Bus1 프로젝트가 탄생했고, 이는 범용 커널 IPC 기반 구조를 지향합니다. 하지만 역시 커널 메인라인에는 합류하지 못했고, dbus-broker의 사용자 공간 최적화가 실질적인 대안이 되었습니다.

컨테이너 환경의 D-Bus(D-Bus in Container Environments)

Docker, Podman, LXC 등 컨테이너 환경에서 D-Bus를 사용하려면 네임스페이스 격리, 소켓 경로, 자격 증명(Credential) 전달 등 여러 문제를 해결해야 합니다. 컨테이너가 호스트의 시스템 버스에 접근하는 방식과 내부에서 독립적인 D-Bus 데몬을 운영하는 방식은 보안과 격리 수준에서 큰 차이를 보입니다.

네임스페이스 격리

컨테이너(Container) 환경에서 D-Bus와 리눅스 네임스페이스(Namespace)의 관계를 이해하는 것은 올바른 구성의 전제 조건입니다.

• 마운트(Mount) 네임스페이스(Mount Namespace): 시스템 버스 소켓이 컨테이너 안에 보이지 않으면 시스템 버스에 접근할 수 없습니다. 바인드 마운트(Bind Mount)로 소켓을 공유하거나, 컨테이너 내부에서 독립 데몬을 실행해야 합니다.
• PID 네임스페이스(PID Namespace): SCM_CREDENTIALS로 전달되는 PID가 호스트와 컨테이너에서 다릅니다. 컨테이너 내부 PID 1인 프로세스가 호스트에서는 전혀 다른 PID를 가지므로, D-Bus 정책의 PID 기반 규칙이 예상과 다르게 동작합니다.
• 사용자 네임스페이스(User Namespace): UID 매핑(Mapping)으로 인해 D-Bus 정책의 UID 기반 규칙이 예상과 다르게 동작할 수 있습니다. 컨테이너 내부 root(UID 0)가 호스트에서는 비특권(Unprivileged) UID로 매핑됩니다.
• 네트워크 네임스페이스(Network Namespace): 추상 소켓은 네트워크 네임스페이스에 바인딩됩니다. 별도 네트워크 네임스페이스를 사용하는 컨테이너에서는 호스트의 추상 소켓 기반 세션 버스에 접근할 수 없습니다.
• Flatpak/Snap: 샌드박스(Sandbox) 내 애플리케이션을 위한 D-Bus 프록시(xdg-dbus-proxy)를 사용하여 허용된 인터페이스만 노출합니다.

컨테이너에서 D-Bus가 필요한 이유

대부분의 단순 컨테이너(마이크로서비스, 웹 서버 등)는 D-Bus가 필요하지 않습니다. 그러나 다음과 같은 시나리오에서는 컨테이너 내부에서 D-Bus 통신이 필수적입니다.

호스트 소켓 바인드 마운트

가장 간단한 방법은 호스트의 시스템 버스 소켓을 컨테이너에 바인드 마운트하는 것입니다. 컨테이너 프로세스가 호스트의 dbus-daemon에 직접 연결됩니다.

# 호스트 시스템 버스 소켓을 컨테이너에 공유
docker run -it \
  -v /run/dbus/system_bus_socket:/run/dbus/system_bus_socket \
  ubuntu:24.04 bash

# 컨테이너 내부에서 호스트의 시스템 버스에 접근
apt-get update && apt-get install -y dbus
busctl list --system          # 호스트의 서비스 목록이 보임
busctl tree org.freedesktop.systemd1  # 호스트 systemd 객체 탐색

PID/UID 불일치 문제: 바인드 마운트 환경에서 호스트의 dbus-daemon은 SO_PEERCRED로 연결 프로세스의 자격 증명을 확인합니다. PID 네임스페이스 사용 시 커널이 호스트 관점의 PID를 반환하므로 D-Bus 정책은 정상 동작하지만, GetConnectionUnixProcessID 같은 API로 조회한 PID는 컨테이너 내부에서 의미가 없습니다.

# 컨테이너 내부에서 자신의 D-Bus 연결 정보 확인
busctl --system call org.freedesktop.DBus /org/freedesktop/DBus \
  org.freedesktop.DBus GetConnectionUnixProcessID s ":1.234"
# → 호스트 PID가 반환됨 (컨테이너 PID와 다름)

컨테이너 내부 독립 D-Bus 데몬

컨테이너가 자체적인 D-Bus 환경이 필요하면서 호스트와 격리되어야 하는 경우, 컨테이너 내부에서 독립적인 dbus-daemon을 실행합니다.

# Dockerfile: 독립 D-Bus 데몬이 있는 컨테이너
FROM ubuntu:24.04

RUN apt-get update && apt-get install -y \
    dbus \
    && rm -rf /var/lib/apt/lists/*

# machine-id 생성 (D-Bus 필수)
RUN dbus-uuidgen --ensure=/etc/machine-id

# 시스템 버스 소켓 디렉터리 생성
RUN mkdir -p /run/dbus

# dbus-daemon을 포그라운드로 실행
CMD ["dbus-daemon", "--system", "--nofork", "--nopidfile"]

여러 프로세스가 필요한 경우 슈퍼바이저(Supervisor) 패턴을 사용합니다.

# entrypoint.sh: dbus-daemon을 백그라운드로 시작 후 주 프로세스 실행
#!/bin/bash
mkdir -p /run/dbus
dbus-uuidgen --ensure=/etc/machine-id
dbus-daemon --system --nofork &
# D-Bus 소켓이 준비될 때까지 대기
while [ ! -S /run/dbus/system_bus_socket ]; do sleep 0.1; done
# 주 애플리케이션 실행
exec "$@"

systemd 컨테이너와 D-Bus

systemd를 PID 1로 실행하는 컨테이너에서는 dbus.socket 유닛이 자동으로 활성화되어 dbus-daemon(또는 dbus-broker)을 소켓 활성화(Socket Activation) 방식으로 시작합니다.

# systemd를 PID 1로 실행하는 Docker 컨테이너
docker run -d --name systemd-container \
  --privileged \
  --cgroupns=host \
  -v /sys/fs/cgroup:/sys/fs/cgroup:rw \
  --tmpfs /run \
  --tmpfs /run/lock \
  ubuntu-systemd:24.04 /sbin/init

# 컨테이너 내부에서 D-Bus 서비스 확인
docker exec systemd-container busctl list --system

--privileged 플래그는 모든 Linux 기능(Capability)을 부여하므로 보안 위험이 큽니다. 최소 권한 원칙을 따르려면 필요한 기능만 명시적으로 추가합니다.

# 최소 권한으로 systemd 컨테이너 실행 (cgroup v2)
docker run -d --name systemd-min \
  --cap-add SYS_ADMIN \
  --cap-add SYS_BOOT \
  --cgroupns=host \
  --security-opt seccomp=unconfined \
  -v /sys/fs/cgroup:/sys/fs/cgroup:rw \
  --tmpfs /run \
  --tmpfs /run/lock \
  --stop-signal SIGRTMIN+3 \
  ubuntu-systemd:24.04 /sbin/init

Podman과 Docker 비교

Podman은 데몬리스(Daemonless) 아키텍처와 루트리스(Rootless) 모드로 D-Bus 관련 동작이 Docker와 다릅니다.

# Podman: systemd 컨테이너 (자동 D-Bus 구성)
podman run -d --name systemd-pod \
  --systemd=true \
  ubuntu-systemd:24.04 /sbin/init

# Podman이 자동으로 처리하는 항목:
#   - /run을 tmpfs로 마운트
#   - /sys/fs/cgroup 적절한 마운트
#   - SIGRTMIN+3 정지 시그널 설정
#   - 환경 변수 container=podman 설정

# Podman: 호스트 세션 버스를 루트리스 컨테이너에 공유
podman run -it \
  -v $XDG_RUNTIME_DIR/bus:$XDG_RUNTIME_DIR/bus \
  -e DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus" \
  ubuntu:24.04 bash

컨테이너 D-Bus 보안(Container D-Bus Security)

호스트 시스템 버스를 컨테이너에 노출하면 공격 표면(Attack Surface)이 크게 확장됩니다. 주요 위험과 완화 방법을 정리합니다.

호스트 버스 노출 시 주요 위험:

• org.freedesktop.systemd1.Manager.StartUnit — 호스트의 임의 서비스 시작/중지
• org.freedesktop.login1.Manager.PowerOff — 호스트 전원 종료
• org.freedesktop.NetworkManager.Settings.AddConnection — 네트워크 설정 변경
• org.freedesktop.PolicyKit1.Authority.CheckAuthorization — Polkit 우회 시도

완화 전략 1: D-Bus 정책 파일로 접근 제한

<!-- /etc/dbus-1/system.d/container-restrict.conf -->
<!-- 특정 UID(컨테이너 프로세스)의 접근을 제한 -->
<busconfig>
  <policy user="container-user">
    <!-- 기본 거부 -->
    <deny send_destination="*"/>
    <!-- 특정 인터페이스만 허용 -->
    <allow send_destination="org.freedesktop.hostname1"/>
    <allow send_destination="org.freedesktop.timedate1"/>
  </policy>
</busconfig>

완화 전략 2: xdg-dbus-proxy 필터링

# xdg-dbus-proxy로 허용된 인터페이스만 노출
xdg-dbus-proxy \
  unix:path=/run/dbus/system_bus_socket \
  /run/container-dbus-proxy \
  --filter \
  --talk=org.freedesktop.hostname1 \
  --talk=org.freedesktop.timedate1 \
  --call=org.freedesktop.DBus=Hello \
  --call=org.freedesktop.DBus=AddMatch

# 컨테이너는 프록시 소켓을 사용
docker run -it \
  -v /run/container-dbus-proxy:/run/dbus/system_bus_socket \
  ubuntu:24.04 bash

완화 전략 3: AppArmor/SELinux 프로파일

# AppArmor: D-Bus 접근 제한 프로파일
profile container-dbus flags=(attach_disconnected) {
  # D-Bus 시스템 버스 소켓 접근 허용
  /run/dbus/system_bus_socket rw,

  # 특정 D-Bus 대상만 허용
  dbus (send) bus=system peer=(name=org.freedesktop.hostname1),
  dbus (receive) bus=system peer=(name=org.freedesktop.hostname1),

  # 나머지 D-Bus 통신 거부
  deny dbus bus=system,
}

# SELinux: 컨테이너의 D-Bus 소켓 접근 제어
# container_t 도메인에서 system_dbusd_t로의 통신 허용
allow container_t system_dbusd_t:unix_stream_socket connectto;
allow container_t system_dbusd_var_run_t:sock_file write;

주요 D-Bus 서비스(Major D-Bus Services)

현대 리눅스 시스템에서 시스템 버스를 사용하는 주요 서비스들입니다.

# 시스템 버스의 모든 서비스 목록
busctl list --system

# 특정 서비스의 객체 트리
busctl tree org.freedesktop.systemd1

# systemd 버전 프로퍼티 조회
busctl get-property org.freedesktop.systemd1 \
  /org/freedesktop/systemd1 \
  org.freedesktop.systemd1.Manager Version

# NetworkManager 상태 조회
busctl call org.freedesktop.NetworkManager \
  /org/freedesktop/NetworkManager \
  org.freedesktop.DBus.Properties Get ss \
  org.freedesktop.NetworkManager State

D-Bus 도구(Tools)

도구 비교

busctl 사용법

# 시스템 버스의 모든 서비스 나열
busctl list --system

# 서비스의 객체 트리 표시
busctl tree org.freedesktop.systemd1

# 특정 객체의 인터페이스·메서드·프로퍼티 조회
busctl introspect org.freedesktop.systemd1 /org/freedesktop/systemd1

# 메서드 호출 (인자 타입과 값 전달)
busctl call org.freedesktop.systemd1 \
  /org/freedesktop/systemd1 \
  org.freedesktop.systemd1.Manager \
  StartUnit ss "sshd.service" "replace"

# 프로퍼티 읽기
busctl get-property org.freedesktop.systemd1 \
  /org/freedesktop/systemd1 \
  org.freedesktop.systemd1.Manager Version

# 실시간 모니터링
busctl monitor org.freedesktop.NetworkManager

# pcap 형식으로 캡처 (Wireshark로 분석 가능)
busctl capture org.freedesktop.systemd1 > dbus-capture.pcap

dbus-send 사용법

# systemd에서 유닛 시작
dbus-send --system --print-reply --dest=org.freedesktop.systemd1 \
  /org/freedesktop/systemd1 \
  org.freedesktop.systemd1.Manager.StartUnit \
  string:"sshd.service" string:"replace"

# 프로퍼티 읽기
dbus-send --system --print-reply --dest=org.freedesktop.systemd1 \
  /org/freedesktop/systemd1 \
  org.freedesktop.DBus.Properties.Get \
  string:"org.freedesktop.systemd1.Manager" string:"Version"

# 세션 버스에서 데스크톱 알림 보내기
dbus-send --session --print-reply --dest=org.freedesktop.Notifications \
  /org/freedesktop/Notifications \
  org.freedesktop.Notifications.Notify \
  string:"test" uint32:0 string:"" string:"D-Bus 테스트" \
  string:"이것은 D-Bus 알림입니다" array:string:"" dict:string:string:"" int32:5000

dbus-monitor 사용법

# 시스템 버스의 모든 메시지 모니터링
dbus-monitor --system

# 특정 인터페이스의 시그널만 필터링
dbus-monitor --system "type='signal',interface='org.freedesktop.NetworkManager'"

# 특정 서비스로 향하는 메서드 호출만 필터링
dbus-monitor --system "type='method_call',destination='org.freedesktop.systemd1'"

# PropertiesChanged 시그널 모니터링
dbus-monitor --system "type='signal',member='PropertiesChanged'"

첫 번째 D-Bus 실습(Hello World)

명령줄 도구만으로 D-Bus 서비스와 대화하는 완전한 실습 시나리오입니다. 추가 설치가 필요 없으며, 리눅스 시스템이라면 바로 실행할 수 있습니다.

1단계: 버스 탐색

# 1. 시스템에 연결된 모든 D-Bus 서비스 목록 확인
busctl list --system

# 2. systemd 서비스의 객체 트리 구조 확인
busctl tree org.freedesktop.systemd1

# 3. 특정 객체의 인터페이스와 멤버 목록 확인
busctl introspect org.freedesktop.systemd1 \
  /org/freedesktop/systemd1 \
  org.freedesktop.systemd1.Manager

2단계: 프로퍼티 읽기

# systemd 버전 읽기
busctl get-property org.freedesktop.systemd1 \
  /org/freedesktop/systemd1 \
  org.freedesktop.systemd1.Manager Version
# s "254"

# systemd 전체 상태 읽기
busctl get-property org.freedesktop.systemd1 \
  /org/freedesktop/systemd1 \
  org.freedesktop.systemd1.Manager SystemState
# s "running"

# NetworkManager 연결 검사 활성화 여부
busctl get-property org.freedesktop.NetworkManager \
  /org/freedesktop/NetworkManager \
  org.freedesktop.NetworkManager ConnectivityCheckEnabled
# b true

3단계: 메서드 호출

# 실행 중인 systemd 유닛 목록 조회 (반환 타입: a(ssssssouso))
busctl call org.freedesktop.systemd1 \
  /org/freedesktop/systemd1 \
  org.freedesktop.systemd1.Manager \
  ListUnits

# 특정 유닛 객체 경로 가져오기 (인자 타입: s = 문자열)
busctl call org.freedesktop.systemd1 \
  /org/freedesktop/systemd1 \
  org.freedesktop.systemd1.Manager \
  GetUnit s "NetworkManager.service"
# o "/org/freedesktop/systemd1/unit/NetworkManager_2eservice"

# 반환된 객체 경로로 유닛 상태 확인
busctl get-property org.freedesktop.systemd1 \
  /org/freedesktop/systemd1/unit/NetworkManager_2eservice \
  org.freedesktop.systemd1.Unit ActiveState
# s "active"

4단계: 시그널 구독

# NetworkManager 상태 변경 시그널 실시간 관찰
# (Wi-Fi 연결/해제 시 출력됨 — Ctrl+C로 종료)
dbus-monitor --system \
  "type='signal',interface='org.freedesktop.NetworkManager'"

# systemd 유닛 생성 이벤트 관찰
dbus-monitor --system \
  "type='signal',sender='org.freedesktop.systemd1',member='UnitNew'"

# 다른 터미널에서 서비스를 재시작하면 위 터미널에 이벤트가 출력됨
# systemctl --user restart some.service

5단계: Python으로 시작하기

터미널 도구 대신 Python으로 동일한 작업을 프로그래밍 방식으로 수행합니다. subprocess를 이용한 가장 간단한 방법으로, 추가 라이브러리가 필요 없습니다.

import subprocess, re

def dbus_get_property(bus_name, obj_path, iface, prop):
    result = subprocess.run(
        ["busctl", "get-property",
         bus_name, obj_path, iface, prop],
        capture_output=True, text=True
    )
    return result.stdout.strip()

# systemd 버전과 상태 출력
version = dbus_get_property(
    "org.freedesktop.systemd1",
    "/org/freedesktop/systemd1",
    "org.freedesktop.systemd1.Manager",
    "Version"
)
state = dbus_get_property(
    "org.freedesktop.systemd1",
    "/org/freedesktop/systemd1",
    "org.freedesktop.systemd1.Manager",
    "SystemState"
)
print(f"systemd {version}, state={state}")
# systemd s "254", state=s "running"

더 본격적인 Python D-Bus 프로그래밍(시그널 구독, 비동기 처리)은 아래 Python 예제 섹션을 참고하세요.

프로그래밍 인터페이스(Programming Interfaces)

D-Bus 프로그래밍 라이브러리는 여러 가지가 있으며, 용도에 따라 선택합니다.

sd-bus 예제: 클라이언트(메서드 호출)

#include <stdio.h>
#include <systemd/sd-bus.h>

int main(void) {
    sd_bus *bus = NULL;
    sd_bus_error error = SD_BUS_ERROR_NULL;
    sd_bus_message *reply = NULL;
    const char *version;
    int r;

    /* 시스템 버스에 연결 */
    r = sd_bus_open_system(&bus);
    if (r < 0) {
        fprintf(stderr, "버스 연결 실패: %s\n", strerror(-r));
        return 1;
    }

    /* systemd Manager의 Version 프로퍼티 읽기 */
    r = sd_bus_get_property(
        bus,
        "org.freedesktop.systemd1",           /* 버스 이름 */
        "/org/freedesktop/systemd1",           /* 객체 경로 */
        "org.freedesktop.systemd1.Manager",    /* 인터페이스 */
        "Version",                              /* 프로퍼티 이름 */
        &error,
        &reply,
        "s"                                      /* 프로퍼티 타입 */
    );
    if (r < 0) {
        fprintf(stderr, "프로퍼티 읽기 실패: %s\n", error.message);
        goto finish;
    }

    r = sd_bus_message_read(reply, "s", &version);
    if (r < 0) {
        fprintf(stderr, "메시지 파싱 실패: %s\n", strerror(-r));
        goto finish;
    }

    printf("systemd version: %s\n", version);

finish:
    sd_bus_error_free(&error);
    sd_bus_message_unref(reply);
    sd_bus_unref(bus);
    return r < 0 ? 1 : 0;
}

# 컴파일
gcc -o dbus-version dbus-version.c $(pkg-config --cflags --libs libsystemd)

sd-bus 예제: 서비스(메서드 노출)

#include <stdio.h>
#include <stdlib.h>
#include <systemd/sd-bus.h>

/* 메서드 핸들러: Greeting 메서드 */
static int method_greeting(
        sd_bus_message *msg,
        void *userdata,
        sd_bus_error *ret_error) {
    const char *name;
    int r;

    r = sd_bus_message_read(msg, "s", &name);
    if (r < 0)
        return r;

    char buf[256];
    snprintf(buf, sizeof(buf), "안녕하세요, %s!", name);

    return sd_bus_reply_method_return(msg, "s", buf);
}

/* 인터페이스 vtable 정의 */
static const sd_bus_vtable example_vtable[] = {
    SD_BUS_VTABLE_START(0),
    SD_BUS_METHOD("Greeting", "s", "s", method_greeting,
                 SD_BUS_VTABLE_UNPRIVILEGED),
    SD_BUS_VTABLE_END,
};

int main(void) {
    sd_bus *bus = NULL;
    sd_bus_slot *slot = NULL;
    int r;

    r = sd_bus_open_user(&bus);
    if (r < 0) return 1;

    /* vtable을 객체 경로에 등록 */
    r = sd_bus_add_object_vtable(
        bus, &slot,
        "/com/example/Greeter",       /* 객체 경로 */
        "com.example.Greeter",         /* 인터페이스 이름 */
        example_vtable,
        NULL
    );
    if (r < 0) return 1;

    /* 잘 알려진 이름 요청 */
    r = sd_bus_request_name(bus, "com.example.Greeter", 0);
    if (r < 0) return 1;

    /* 이벤트 루프 */
    for (;;) {
        r = sd_bus_process(bus, NULL);
        if (r < 0) break;
        if (r > 0) continue;

        r = sd_bus_wait(bus, (uint64_t)-1);
        if (r < 0) break;
    }

    sd_bus_slot_unref(slot);
    sd_bus_unref(bus);
    return 0;
}

# 서비스를 빌드하고 실행
gcc -o greeter-service greeter-service.c $(pkg-config --cflags --libs libsystemd)
./greeter-service &

# 다른 터미널에서 호출
busctl --user call com.example.Greeter \
  /com/example/Greeter \
  com.example.Greeter \
  Greeting s "세계"
# 출력: s "안녕하세요, 세계!"

Python 예제

import dbus

# 시스템 버스에 연결
bus = dbus.SystemBus()

# NetworkManager 프록시 객체 획득
nm_proxy = bus.get_object(
    'org.freedesktop.NetworkManager',
    '/org/freedesktop/NetworkManager'
)

# 인터페이스를 통한 메서드 호출
nm_iface = dbus.Interface(nm_proxy, 'org.freedesktop.NetworkManager')
devices = nm_iface.GetDevices()

# Properties 인터페이스로 프로퍼티 읽기
props_iface = dbus.Interface(nm_proxy, 'org.freedesktop.DBus.Properties')
state = props_iface.Get('org.freedesktop.NetworkManager', 'State')

print(f"NetworkManager 상태: {state}")
print(f"장치 수: {len(devices)}")
for dev_path in devices:
    dev_proxy = bus.get_object('org.freedesktop.NetworkManager', dev_path)
    dev_props = dbus.Interface(dev_proxy, 'org.freedesktop.DBus.Properties')
    iface_name = dev_props.Get('org.freedesktop.NetworkManager.Device', 'Interface')
    print(f"  장치: {iface_name} ({dev_path})")

# 시그널 구독 예제 (GLib 이벤트 루프 필요)
import dbus
from dbus.mainloop.glib import DBusGMainLoop
from gi.repository import GLib

DBusGMainLoop(set_as_default=True)
bus = dbus.SystemBus()

def on_properties_changed(interface, changed, invalidated):
    print(f"인터페이스: {interface}")
    for key, value in changed.items():
        print(f"  변경: {key} = {value}")

bus.add_signal_receiver(
    on_properties_changed,
    signal_name='PropertiesChanged',
    dbus_interface='org.freedesktop.DBus.Properties',
    bus_name='org.freedesktop.NetworkManager'
)

loop = GLib.MainLoop()
print("프로퍼티 변경 모니터링 중... (Ctrl+C로 종료)")
loop.run()

성능과 대안(Performance & Alternatives)

D-Bus 오버헤드 분석

D-Bus의 성능 오버헤드는 다음 요소에서 발생합니다:

• 직렬화/역직렬화(Serialization): 메시지 본문을 D-Bus 와이어 포맷(Wire Format)으로 변환. 데이터 크기에 비례
• 컨텍스트 스위치(Context Switch): 클라이언트 → 커널 → 데몬 → 커널 → 서비스 경로에서 최소 4회 컨텍스트 스위치 발생
• 데몬 홉(Daemon Hop): 모든 메시지가 버스 데몬을 거쳐야 하므로, 직접 소켓 통신 대비 지연(Latency) 증가
• 정책 검사: 매 메시지마다 접근 제어 규칙을 평가

메시지 지연 벤치마크

다음은 D-Bus 메서드 호출의 왕복 지연 근사치입니다. 실제 값은 하드웨어, 커널 버전, 부하(Load)에 따라 다릅니다.

dbus-daemon vs dbus-broker 성능

메시지 크기별 처리량

UNIX_FD를 이용한 대용량 데이터 전달

대용량 데이터를 D-Bus 메시지 본문에 직렬화하면 성능이 급격히 저하됩니다. 대신 memfd_create()로 공유 메모리(Shared Memory)를 만들고, 그 파일 디스크립터(UNIX_FD)를 D-Bus로 전달하면 제로카피(Zero-copy)에 가까운 성능을 얻을 수 있습니다.

# 패턴: 대용량 데이터를 fd로 전달하는 서비스 설계
# 1. 서비스가 memfd_create()로 익명 파일 생성
# 2. 데이터를 memfd에 write()
# 3. fd를 D-Bus METHOD_RETURN의 'h' 타입으로 반환
# 4. 클라이언트가 fd를 받아 mmap()으로 직접 접근

# 실제 예: PipeWire는 오디오/비디오 버퍼를 memfd+fd-passing으로 전달
# 실제 예: Flatpak Portal은 파일 선택 결과를 fd로 전달

비동기 배치 호출

sd_bus_call_async()를 사용하면 여러 메서드 호출을 응답을 기다리지 않고 연속으로 전송할 수 있습니다. 응답은 이벤트 루프에서 콜백(Callback)으로 처리됩니다. 이 방식은 단일 호출의 지연 시간을 줄이지는 않지만, 여러 호출의 총 소요 시간을 크게 단축합니다.

D-Bus 대안 기술

디버깅

자주 발생하는 오류

디버깅 기법

# 1. 서비스 존재 여부 확인
busctl list --system | grep NetworkManager

# 2. 서비스의 프로세스 정보 확인
busctl status org.freedesktop.NetworkManager

# 3. 실시간 메시지 추적
busctl monitor org.freedesktop.NetworkManager

# 4. D-Bus 데몬 자체의 통계
busctl call org.freedesktop.DBus /org/freedesktop/DBus \
  org.freedesktop.DBus.Debug.Stats GetStats

# 5. journalctl로 D-Bus 관련 로그 확인
journalctl -u dbus.service --since "5 minutes ago"

# 6. strace로 소켓 통신 추적
strace -e trace=sendmsg,recvmsg -p $(pidof dbus-daemon) 2>&1 | head -50

# 7. dbus-daemon 상세 로그 활성화
# /usr/share/dbus-1/system.conf에서 syslog="true" 설정 후:
DBUS_VERBOSE=1 dbus-daemon --system --nofork

디버깅용 환경 변수

실전 트러블슈팅 시나리오

시나리오 1: 서비스가 시작되지 않음 (ServiceUnknown)

# 1단계: 서비스가 버스에 등록되어 있는지 확인
busctl list --system | grep "원하는.서비스.이름"

# 2단계: D-Bus .service 파일이 존재하는지 확인
ls /usr/share/dbus-1/system-services/ | grep "원하는.서비스"

# 3단계: systemd 유닛 상태 확인
systemctl status 해당-서비스.service
journalctl -u 해당-서비스.service --since "5 min ago" --no-pager

# 4단계: 수동으로 서비스 시작 시도
systemctl start 해당-서비스.service
# 실패하면 journalctl에서 원인 확인

시나리오 2: 권한 거부 (AccessDenied)

# 1단계: 호출자의 UID/GID 확인
id

# 2단계: 해당 서비스의 D-Bus 정책 파일 찾기
ls /usr/share/dbus-1/system.d/ /etc/dbus-1/system.d/ | grep "서비스이름"

# 3단계: 정책 파일에서 허용 규칙 확인
grep -A5 'send_destination.*서비스이름' /usr/share/dbus-1/system.d/서비스이름.conf

# 4단계: SELinux AVC 거부 여부 확인 (RHEL/Fedora)
ausearch -m AVC --recent | grep dbus

# 5단계: AppArmor 거부 여부 확인 (Ubuntu/SUSE)
journalctl -k | grep DENIED | grep dbus

시나리오 3: 메서드 호출 타임아웃 (TimedOut)

# 1단계: 서비스 프로세스가 살아있는지 확인
busctl status org.서비스.이름

# 2단계: 서비스의 CPU/메모리 상태 확인 (이벤트 루프 블로킹?)
top -p $(busctl status org.서비스.이름 | grep PID | awk '{print $NF}')

# 3단계: 더 긴 타임아웃으로 재시도
busctl call --timeout=60 org.서비스.이름 /경로 인터페이스 메서드

# 4단계: 서비스 로그에서 블로킹 원인 확인
journalctl -u 서비스.service --since "2 min ago" | tail -30

journalctl D-Bus 필터링 패턴

# dbus-daemon 로그
journalctl -u dbus.service --since "10 min ago"

# dbus-broker 로그 (Fedora/RHEL 9+)
journalctl -u dbus-broker.service --since "10 min ago"

# 특정 서비스의 D-Bus 관련 로그만 필터링
journalctl -u NetworkManager --grep "dbus\|DBus\|bus" --since "10 min ago"

# 커널 감사(Audit) 로그에서 D-Bus 관련 항목
journalctl -k --grep "dbus\|avc.*dbus" --since "10 min ago"

Wireshark를 이용한 D-Bus 분석

busctl capture로 생성한 pcap 파일을 Wireshark에서 분석할 수 있습니다. Wireshark는 D-Bus 프로토콜 디섹터(Dissector)를 내장하고 있어, 메시지 헤더와 본문을 구조적으로 볼 수 있습니다.

# 시스템 버스의 특정 서비스 메시지를 캡처
busctl capture --system org.freedesktop.NetworkManager > nm-dbus.pcap

# Wireshark로 열기
wireshark nm-dbus.pcap

D-Bus 프로토콜 상세(Protocol Details)

D-Bus 프로토콜은 바이너리 메시지(Binary Message) 형식으로 정의되며, 각 메시지는 고정 헤더(Fixed Header), 헤더 필드 배열(Header Fields Array), 본문(Body)으로 구성됩니다.

메시지 고정 헤더

모든 D-Bus 메시지는 12바이트 또는 16바이트의 고정 헤더로 시작합니다.

헤더 필드 상세

고정 헤더 뒤에 가변 길이 헤더 필드 배열이 따릅니다. 각 필드는 (코드, VARIANT) 형태입니다.

메시지 타입별 동작

D-Bus 타입 시스템 상세(Type System Details)

D-Bus의 타입 시스템은 시그니처 문자열(Signature String)로 표현되며, 기본 타입(Basic Type)과 컨테이너 타입(Container Type)으로 구분됩니다.

기본 타입 상세

컨테이너 타입과 시그니처

# 시그니처 예시와 busctl 출력

# a{sv}: Properties.GetAll의 반환 타입
busctl call org.freedesktop.NetworkManager \
    /org/freedesktop/NetworkManager \
    org.freedesktop.DBus.Properties GetAll s \
    "org.freedesktop.NetworkManager"
# → a{sv} 23 "Version" s "1.44.2" "State" u 70 ...

# (ssa{sv}): 인트로스펙션 XML의 구조적 표현
# s = 인터페이스 이름
# s = 멤버 이름
# a{sv} = 속성 사전

# VARIANT의 시그니처 확인
busctl get-property org.freedesktop.NetworkManager \
    /org/freedesktop/NetworkManager \
    org.freedesktop.NetworkManager State
# → u 70  (u = UINT32, 70 = NM_STATE_CONNECTED_GLOBAL)

마샬링(Marshaling) 규칙

D-Bus 마샬링은 메모리 정렬(Alignment)을 엄격히 적용합니다. 각 타입은 자신의 정렬 크기의 배수 오프셋에서 시작해야 하며, 필요한 경우 NUL 패딩이 삽입됩니다.

/* sd-bus를 이용한 마샬링 예제 */
#include <systemd/sd-bus.h>

/* a{sv} 사전 마샬링 */
sd_bus_message *msg;
sd_bus_message_new_method_call(bus, &msg,
    "org.example.Service",
    "/org/example/Object",
    "org.example.Interface",
    "Configure");

/* 사전 열기: a{sv} */
sd_bus_message_open_container(msg, 'a', "{sv}");

/* 첫 번째 항목: "Name" → "test" */
sd_bus_message_open_container(msg, 'e', "sv");
sd_bus_message_append(msg, "s", "Name");
sd_bus_message_open_container(msg, 'v', "s");
sd_bus_message_append(msg, "s", "test");
sd_bus_message_close_container(msg);  /* v */
sd_bus_message_close_container(msg);  /* e */

/* 두 번째 항목: "Port" → 8080 */
sd_bus_message_open_container(msg, 'e', "sv");
sd_bus_message_append(msg, "s", "Port");
sd_bus_message_open_container(msg, 'v', "u");
sd_bus_message_append(msg, "u", 8080);
sd_bus_message_close_container(msg);  /* v */
sd_bus_message_close_container(msg);  /* e */

sd_bus_message_close_container(msg);  /* a */

/* 메시지 전송 */
sd_bus_call(bus, msg, 0, &error, &reply);

이름 소유권(Name Ownership)

D-Bus에서 서비스를 식별하는 두 가지 이름 체계가 있습니다.

유니크 이름과 잘 알려진 이름

이름 큐잉(Name Queuing)

잘 알려진 이름에 대해 여러 프로세스가 소유를 요청하면 큐(Queue)에 대기합니다. 현재 소유자가 해제하면 큐의 다음 대기자가 자동으로 소유권을 획득합니다.

# 이름 소유 요청 (RequestName)
busctl call org.freedesktop.DBus /org/freedesktop/DBus \
    org.freedesktop.DBus RequestName su \
    "org.example.MyService" 0

# 반환 코드:
# 1 = DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER (즉시 획득)
# 2 = DBUS_REQUEST_NAME_REPLY_IN_QUEUE (큐에 대기)
# 3 = DBUS_REQUEST_NAME_REPLY_EXISTS (이미 다른 소유자, 큐잉 미요청)
# 4 = DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER (이미 자신이 소유)

# 현재 이름 소유자 확인
busctl call org.freedesktop.DBus /org/freedesktop/DBus \
    org.freedesktop.DBus GetNameOwner s \
    "org.freedesktop.NetworkManager"
# → s ":1.6"

# 이름의 큐 상태 확인
busctl call org.freedesktop.DBus /org/freedesktop/DBus \
    org.freedesktop.DBus ListQueuedOwners s \
    "org.freedesktop.NetworkManager"
# → as 1 ":1.6"

# 이름 소유권 변경 시그널 감시
busctl monitor --match "type='signal',sender='org.freedesktop.DBus',member='NameOwnerChanged'"

/* sd-bus에서 이름 소유 요청 */
#include <systemd/sd-bus.h>

int r;

/* 이름 요청: DBUS_NAME_FLAG_REPLACE_EXISTING | DBUS_NAME_FLAG_ALLOW_REPLACEMENT */
r = sd_bus_request_name(bus,
    "org.example.MyService",
    SD_BUS_NAME_REPLACE_EXISTING | SD_BUS_NAME_ALLOW_REPLACEMENT);

if (r < 0) {
    fprintf(stderr, "이름 요청 실패: %s\n", strerror(-r));
    return r;
}
/* r > 0이면 소유 성공 */

systemd 연동(systemd Integration)

systemd는 D-Bus를 핵심 통신 채널로 사용합니다. systemd-logind, systemd-resolved, systemd-networkd 등 주요 서비스가 D-Bus 인터페이스를 노출합니다.

D-Bus 서비스 활성화

D-Bus 활성화(Bus Activation)는 서비스가 아직 실행되지 않았을 때 첫 메서드 호출 시 자동으로 서비스를 시작하는 메커니즘입니다.

# D-Bus 서비스 파일
# /usr/share/dbus-1/system-services/org.example.MyService.service
[D-BUS Service]
Name=org.example.MyService
Exec=/usr/bin/my-service
User=root
SystemdService=my-service.service

# 대응하는 systemd 유닛 파일
# /etc/systemd/system/my-service.service
[Unit]
Description=My D-Bus Service
After=dbus.socket

[Service]
Type=dbus
BusName=org.example.MyService
ExecStart=/usr/bin/my-service

[Install]
WantedBy=multi-user.target
Alias=dbus-org.example.MyService.service

systemd-logind D-Bus API 실전

# 현재 세션 목록
busctl call org.freedesktop.login1 \
    /org/freedesktop/login1 \
    org.freedesktop.login1.Manager \
    ListSessions
# → a(susso) 2 1 1000 "user" "/org/freedesktop/login1/session/_31" ...

# 시스템 전원 관리
busctl call org.freedesktop.login1 \
    /org/freedesktop/login1 \
    org.freedesktop.login1.Manager \
    PowerOff b true
# → Polkit 인증 요청 발생

# Inhibitor Lock (전원 관리 방지)
busctl call org.freedesktop.login1 \
    /org/freedesktop/login1 \
    org.freedesktop.login1.Manager \
    Inhibit ssss \
    "shutdown:sleep" "MyApp" "작업 진행 중" "delay"
# → h 0  (파일 디스크립터 반환 — 닫으면 잠금 해제)

# PrepareForShutdown 시그널 모니터링
busctl monitor org.freedesktop.login1 \
    --match "interface='org.freedesktop.login1.Manager',member='PrepareForShutdown'"

sd-bus 서비스 작성 완전 예제

/* sd-bus를 이용한 완전한 D-Bus 서비스 예제 */
#include <stdio.h>
#include <stdlib.h>
#include <systemd/sd-bus.h>
#include <systemd/sd-event.h>

static int counter = 0;

/* 메서드 핸들러: Increment */
static int method_increment(sd_bus_message *msg,
                             void *userdata,
                             sd_bus_error *error)
{
    int32_t delta;
    int r;

    r = sd_bus_message_read(msg, "i", &delta);
    if (r < 0)
        return r;

    counter += delta;

    /* PropertiesChanged 시그널 발행 */
    sd_bus_emit_properties_changed(
        sd_bus_message_get_bus(msg),
        "/org/example/Counter",
        "org.example.Counter",
        "Value", NULL);

    return sd_bus_reply_method_return(msg, "i", counter);
}

/* 프로퍼티 getter: Value */
static int property_get_value(sd_bus *bus,
    const char *path, const char *iface,
    const char *property, sd_bus_message *reply,
    void *userdata, sd_bus_error *error)
{
    return sd_bus_message_append(reply, "i", counter);
}

/* 인터페이스 vtable */
static const sd_bus_vtable counter_vtable[] = {
    SD_BUS_VTABLE_START(0),
    SD_BUS_METHOD("Increment", "i", "i",
        method_increment, SD_BUS_VTABLE_UNPRIVILEGED),
    SD_BUS_PROPERTY("Value", "i",
        property_get_value, 0,
        SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
    SD_BUS_SIGNAL("Overflow", "i", 0),
    SD_BUS_VTABLE_END,
};

int main(void) {
    sd_bus *bus = NULL;
    sd_bus_slot *slot = NULL;

    sd_bus_open_system(&bus);

    /* 객체에 인터페이스 등록 */
    sd_bus_add_object_vtable(bus, &slot,
        "/org/example/Counter",
        "org.example.Counter",
        counter_vtable, NULL);

    /* 버스 이름 요청 */
    sd_bus_request_name(bus,
        "org.example.Counter", 0);

    /* 이벤트 루프 실행 */
    for (;;) {
        sd_bus_process(bus, NULL);
        sd_bus_wait(bus, (uint64_t)-1);
    }

    sd_bus_slot_unref(slot);
    sd_bus_unref(bus);
    return 0;
}

컨테이너 환경(Container Environment Details)

컨테이너에서 D-Bus를 사용하는 패턴과 보안 고려 사항을 상세히 다룹니다.

컨테이너 D-Bus 접근 패턴

# 패턴 1: 호스트 시스템 버스 바인드 마운트
podman run --rm -it \
    -v /run/dbus/system_bus_socket:/run/dbus/system_bus_socket:ro \
    my-container busctl list
# ⚠ 호스트의 모든 D-Bus 서비스에 접근 가능 — 보안 위험

# 패턴 2: xdg-dbus-proxy로 필터링
xdg-dbus-proxy \
    unix:path=/run/dbus/system_bus_socket \
    /run/container-dbus-socket \
    --filter \
    --talk=org.freedesktop.NetworkManager \
    --see=org.freedesktop.login1
# --talk: 메서드 호출과 시그널 수신 허용
# --see: 이름 존재 확인만 허용 (호출 불가)

# 패턴 3: 컨테이너 내부 독립 D-Bus
# Dockerfile에서:
# RUN dbus-uuidgen > /var/lib/dbus/machine-id
# CMD ["dbus-daemon", "--system", "--fork"] && exec my-service

# 패턴 4: Kubernetes에서 D-Bus 소켓 공유 (hostPath)
# volumes:
#   - name: dbus-socket
#     hostPath:
#       path: /run/dbus/system_bus_socket
#       type: Socket

커널 측 IPC 최적화(Kernel IPC Optimization)

D-Bus 성능은 커널의 AF_UNIX 소켓 구현에 크게 의존합니다. 커널 측 최적화 기법과 dbus-broker의 성능 향상 전략을 살펴봅니다.

AF_UNIX 소켓 최적화

성능 비교 측정

# dbus-broker vs dbus-daemon 벤치마크
# dbus-send를 이용한 간단한 왕복 시간 측정

# 1000회 Ping 호출 시간 측정
time for i in $(seq 1 1000); do
    busctl call org.freedesktop.DBus \
        /org/freedesktop/DBus \
        org.freedesktop.DBus.Peer Ping >/dev/null
done

# perf로 dbus-broker 핫스팟 분석
perf record -g -p $(pidof dbus-broker) -- sleep 10
perf report --sort dso,symbol

# strace로 시스템 콜(System Call) 통계
strace -c -p $(pidof dbus-broker) -e trace=sendmsg,recvmsg,epoll_wait -- sleep 5

# busctl monitor로 메시지 속도 관찰
busctl monitor --system 2>&1 | pv -l -i 5 > /dev/null
# → 초당 처리 메시지 수 확인

실전 예제 종합(Practical Examples)

gdbus 명령어 예제

# gdbus (GLib 기반 D-Bus 도구)

# 인트로스펙션
gdbus introspect --system \
    --dest org.freedesktop.NetworkManager \
    --object-path /org/freedesktop/NetworkManager

# 메서드 호출
gdbus call --system \
    --dest org.freedesktop.NetworkManager \
    --object-path /org/freedesktop/NetworkManager \
    --method org.freedesktop.DBus.Properties.Get \
    "org.freedesktop.NetworkManager" "State"
# → (<uint32 70>,)

# 시그널 모니터링
gdbus monitor --system \
    --dest org.freedesktop.NetworkManager \
    --object-path /org/freedesktop/NetworkManager

Python D-Bus 예제

#!/usr/bin/env python3
# pydbus를 이용한 D-Bus 클라이언트
from pydbus import SystemBus
from gi.repository import GLib

bus = SystemBus()

# NetworkManager 프록시 객체 생성
nm = bus.get("org.freedesktop.NetworkManager")

# 프로퍼티 읽기
print(f"NM Version: {nm.Version}")
print(f"NM State: {nm.State}")

# 메서드 호출: 모든 디바이스 경로 가져오기
devices = nm.GetDevices()
for dev_path in devices:
    dev = bus.get("org.freedesktop.NetworkManager", dev_path)
    print(f"  {dev.Interface}: type={dev.DeviceType}, state={dev.State}")

# 시그널 수신 (비동기)
def on_state_changed(state):
    states = {10: "ASLEEP", 20: "DISCONNECTED",
              70: "CONNECTED_GLOBAL"}
    print(f"NM state → {states.get(state, state)}")

nm.StateChanged.connect(on_state_changed)

# GLib 이벤트 루프 실행
loop = GLib.MainLoop()
try:
    loop.run()
except KeyboardInterrupt:
    loop.quit()

C 클라이언트 예제

/* sd-bus를 이용한 D-Bus 클라이언트 — NM 상태 조회 */
#include <stdio.h>
#include <systemd/sd-bus.h>

int main(void) {
    sd_bus *bus = NULL;
    sd_bus_error error = SD_BUS_ERROR_NULL;
    sd_bus_message *reply = NULL;
    uint32_t state;
    int r;

    r = sd_bus_open_system(&bus);
    if (r < 0) {
        fprintf(stderr, "버스 연결 실패: %s\n", strerror(-r));
        return 1;
    }

    /* Properties.Get 호출 */
    r = sd_bus_get_property(bus,
        "org.freedesktop.NetworkManager",
        "/org/freedesktop/NetworkManager",
        "org.freedesktop.NetworkManager",
        "State",
        &error, &reply, "u");

    if (r < 0) {
        fprintf(stderr, "프로퍼티 조회 실패: %s\n",
                error.message);
        goto finish;
    }

    sd_bus_message_read(reply, "u", &state);
    printf("NetworkManager State: %u\n", state);

finish:
    sd_bus_error_free(&error);
    sd_bus_message_unref(reply);
    sd_bus_unref(bus);
    return r < 0 ? 1 : 0;
}

gcc -o dbus-client dbus-client.c $(pkg-config --cflags --libs libsystemd)
./dbus-client
# → NetworkManager State: 70

매칭 규칙(Match Rules) 상세

D-Bus 매칭 규칙은 클라이언트가 수신할 시그널이나 메시지를 필터링하는 데 사용됩니다. AddMatch 메서드로 등록합니다.

# busctl monitor에서 매칭 규칙 사용

# NetworkManager의 PropertiesChanged 시그널만 수신
busctl monitor --match "type='signal',\
sender='org.freedesktop.NetworkManager',\
interface='org.freedesktop.DBus.Properties',\
member='PropertiesChanged'"

# 특정 객체 경로 하위의 모든 시그널
busctl monitor --match "type='signal',\
path_namespace='/org/freedesktop/NetworkManager/Devices'"

# dbus-monitor 동등 표현
dbus-monitor --system "type='signal',\
sender='org.freedesktop.login1',\
member='PrepareForShutdown'"

표준 D-Bus 오류 이름

최신 동향 (2025~2026)

D-Bus는 여전히 데스크톱/서비스 IPC의 사실상 표준이지만, 2024~2025년을 기점으로 리눅스 생태계는 D-Bus를 유지하면서도 Varlink로 점진 이행하는 방향으로 크게 움직이고 있습니다. 커널 6.x와 systemd 256~257이 이 흐름의 전환점입니다.

dbus-broker의 지배력 확대

Arch Linux(2024-05부터 기본), Fedora(36부터 기본), openSUSE Tumbleweed, Red Hat Enterprise Linux 9+, Gentoo에서 dbus-broker가 기본 구현이 되었고, Ubuntu도 25.04부터 공식 메타패키지로 포함합니다. 주요 릴리스 특징은 다음과 같습니다.

• dbus-broker 36 (2024-12) — SCM_PIDFD 수신 경로를 사용해 피어 신원을 확인, PID 재사용 레이스 차단.
• dbus-broker 37 (2025-06) — systemd의 Type=notify-reload 지원, launcher의 구성 재로드를 서비스 중단 없이 수행.
• 성능 기준선 — 동일 하드웨어에서 레퍼런스 dbus-daemon 대비 메시지 처리량 3~8배, latency 1/3 수준을 유지.
• cgroup user.* xattr(v6.8 커널) 기반 정책 필터링 — PID 기반보다 훨씬 안정적인 서비스 식별이 가능.

Varlink로의 점진 이행 — systemd 257 (2024-12)

kdbus와 Bus1이 커널에 자리를 잡지 못한 이후, systemd 개발팀은 D-Bus의 구조적 한계(동기 RPC, 흐름 제어(Flow Control) 부재, 대용량 전송 부적합)를 우회하기 위해 Varlink로 서서히 축을 이동하고 있습니다. systemd 257에서 그 방향성이 명확해졌습니다.

• sd-varlink / sd-json 공개 API — libsystemd에 정식 공개된 라이브러리로, D-Bus 의존 없이 Varlink 서비스/클라이언트를 작성할 수 있습니다.
• 인터페이스 수 역전 — systemd 257 기준 Varlink 인터페이스 19개 vs D-Bus API 11개. 신규 기능은 대부분 Varlink부터 제공됩니다.
• 주요 이식 대상 — systemd-importd, systemd-userdbd, systemd-machined(일부), systemd-hostnamed(병행 제공), systemd-resolved(일부) 등.
• D-Bus는 유지 — 기존 클라이언트 호환을 위해 기존 인터페이스는 남기며, 신규 기능만 Varlink 우선입니다.

SCM_PIDFD/SO_PEERPIDFD 기반 신원 검증

커널 6.5에서 도입된 SCM_PIDFD/SO_PEERPIDFD는 D-Bus 인증 모델을 강화했습니다. dbus-broker 36+는 연결 초기에 피어의 pidfd를 획득하고, v6.9의 pidfs 고유 ino로 신원을 식별합니다. 이는 기존 SO_PEERCRED의 PID 재사용 취약점을 근본적으로 제거합니다.

/* dbus-broker 내부에서 피어 pidfd를 획득하는 흐름 */
int peer_pidfd = -1;
socklen_t len = sizeof(peer_pidfd);
if (getsockopt(conn_fd, SOL_SOCKET, SO_PEERPIDFD, &peer_pidfd, &len) == 0) {
    /* pidfs ino로 고유 신원 저장 (v6.9+) */
    struct stat st;
    fstat(peer_pidfd, &st);
    peer->identity_inode = st.st_ino;
}

kdbus/Bus1의 공식 종료

커널 내부 D-Bus 구현을 목표로 했던 kdbus(2013~2016)는 2016년 Linus Torvalds가 메인라인 병합을 거부한 뒤 사실상 중단되었습니다. 후속 프로젝트 Bus1도 2017년 이후 활동이 중단되었습니다. 2025년 기준 커뮤니티는 "커널 내 IPC는 필요 없고, 사용자 공간 dbus-broker/Varlink 조합이 충분히 빠르다"는 결론에 도달했습니다.

데스크톱 생태계의 병행 전략

• GNOME/GTK 4.14+ — 당분간 GIO D-Bus를 유지하지만, Portal(Flatpak) 계층은 Varlink 실험 중.
• KDE Plasma 6 — KDBusAddons 기반 의존 유지, 신규 서비스(kwallet, kwin 내부 제어)에서 D-Bus 사용 지속.
• Flatpak/Portal — xdg-desktop-portal이 D-Bus API를 유지하되, 내부 권한 검증을 SCM_PIDFD로 전환.
• ChromeOS/Android — Binder로 독자 경로(데스크톱 Linux D-Bus와 별개).

dbus-daemon 1.16.0 — 레퍼런스 구현 신규 안정 브랜치 (2024-12)

dbus-broker가 성능 우위를 점령했지만, dbus-daemon(레퍼런스 구현)도 2024년 12월에 신규 안정 브랜치 1.16.0을 출시했습니다. 1.14.x 구식 안정 브랜치와 1.15.x 개발 브랜치를 대체하며, 하위 호환을 유지하면서 여러 실질적인 개선이 포함되었습니다.

dbus-daemon 1.16.0부터: Autotools 빌드 시스템(Build System) 제거, Meson만 지원. 빌드 옵션 이름 변경됨.

• ProcessFD in GetConnectionCredentials() — org.freedesktop.DBus.GetConnectionCredentials() 응답에 ProcessFD 딕셔너리 항목(pidfd)이 추가되어, 수신자가 PID 재사용 없이 안전하게 피어 프로세스 정보를 조회할 수 있습니다.
• .service 탐색 경로 확장 — 시스템 메시지 버스가 /etc와 /run에서도 .service 파일을 로드합니다. dbus-broker 37의 변경과 일치하여 관리자가 시스템 재시작 없이 서비스 활성화 설정을 변경할 수 있습니다.
• close_range() 활용 — 불필요한 파일 디스크립터를 닫을 때 Linux의 close_range() 시스템 콜(System Call)을 사용하여 성능 향상.
• Y2038 안전성 — 32비트 플랫폼에서 내부 타임스탬프를 64비트로 처리, time_t 오버플로 문제 해결. 관련 API가 64비트 타임스탬프와 inode 번호를 반환하도록 업데이트.
• 소켓 경로 변경 — 잘 알려진 시스템 버스 소켓이 기본적으로 런타임 상태 디렉터리(/run)에 위치. systemd 환경에서 dbus-daemon이 root로 기동 후 권한 강하 방식에서 대상 사용자로 직접 기동으로 변경.

systemd 258~259의 Varlink 확장 (2025-09~2025-12)

systemd 257에서 sd-varlink/sd-json이 공개 API로 출시된 이후, 258(2025년 9월)과 259(2025년 11~12월)에서 Varlink 인터페이스가 대폭 확장되었습니다. D-Bus와 Varlink의 기능 동등성(Feature Parity)이 점점 가까워지고 있습니다.

systemd 258부터: 서비스 관리자(PID 1)가 기본 Varlink API를 제공. 유닛 상태 조회와 목록 열거가 D-Bus 없이 가능합니다.

• 서비스 관리자 Varlink API (systemd 258) — io.systemd.Manager Varlink 인터페이스가 추가되어 현재 관리자 상태 조회, 유닛 및 상태 목록 열거가 가능해집니다.
• systemd-udevd Varlink 인터페이스 (systemd 258) — udevd가 Varlink 인터페이스를 통해 런타임 및 수명 주기 작업을 노출합니다. 기존 udevadm과 udevd 간의 비공개 "control" IPC를 대부분 대체합니다.
• 서비스 관리자 Varlink 확장 (systemd 259) — Reload/Reexecute 등 D-Bus 기능 동등성(Feature Parity)이 되는 Varlink 호출 추가, 실행 설정과 필터링 기능 확장.
• 다양한 컴포넌트 Varlink 지원 확장 (systemd 259) — systemd-repart, systemd-resolved(신규 Varlink 메서드 추가), systemd-machined(전체 Varlink API 집합 완성), systemd-creds(자격증명 암호화(Encryption)/복호화(Decryption) Varlink 노출).
• varlink-http-bridge — 로컬 Varlink 서비스를 HTTP를 통해 노출하는 브리지(Bridge). 웹 클라이언트나 Kubernetes 헬스체크에서 systemd 컴포넌트를 직접 조회할 수 있게 됩니다.
• varlinkctl 개선 — list-methods 동사 추가(서비스 메서드 목록), --quiet/--graceful/--timeout 옵션 추가. SSH를 통한 원격 Varlink 호출(ssh-exec: 주소 지정) 지원.

참고자료

• D-Bus Specification (freedesktop.org) — D-Bus 공식 사양 문서입니다
• D-Bus 프로젝트 위키 — freedesktop.org D-Bus 프로젝트 페이지(Page)입니다
• D-Bus Tutorial (freedesktop.org) — D-Bus 프로그래밍 입문 튜토리얼입니다
• D-Bus FAQ (freedesktop.org) — D-Bus에 대한 자주 묻는 질문과 답변을 정리한 문서입니다
• sd-bus API Reference (systemd) — sd-bus 라이브러리 API 문서입니다
• busctl(1) 매뉴얼 (systemd) — D-Bus 버스를 탐색하고 모니터링하는 CLI 도구 문서입니다
• kdbus: critical review (LWN.net) — 커널 내 D-Bus 구현인 kdbus에 대한 심층 분석 기사입니다
• The kdbus saga continues (LWN.net) — kdbus 커널 통합 논의의 후속 전개를 다룬 기사입니다
• Bus1: a new Linux IPC proposal (LWN.net) — kdbus 이후 제안된 Bus1 커널 IPC 메커니즘에 대한 기사입니다
• dbus-broker (GitHub) — 고성능 D-Bus 브로커 구현체입니다
• D-Bus 공식 소스 저장소 (GitLab) — D-Bus 레퍼런스 구현의 공식 소스 코드 저장소입니다
• varlink.org — Varlink 프로토콜 사양, IDL 문법, 기존 구현체 목록 공식 사이트입니다
• sd-varlink(3) (systemd) — systemd 257에서 정식 공개된 Varlink 라이브러리 매뉴얼입니다
• sd-json(3) (systemd) — Varlink 페이로드 직렬화용 JSON 라이브러리 매뉴얼입니다
• systemd: User/Group Record Lookup API via Varlink — Varlink로 제공되는 대표 시스템 서비스 API 문서입니다
• dbus-broker Releases — v36/v37 릴리스 노트에서 SCM_PIDFD와 notify-reload 변경을 확인할 수 있습니다
• Phoronix: Systemd Looking At A Future With More Varlink & Less D-Bus — 2024년 systemd 개발팀의 공식 방향성 발표 기사입니다
• LWN: systemd 257 released — sd-varlink/sd-json 공개와 19개 Varlink 인터페이스 도입을 다룹니다
• Arch Linux: Making dbus-broker our default D-Bus daemon — 주요 배포판의 dbus-broker 기본 채택 공지입니다
• Announcing dbus 1.16.0 (freedesktop.org 메일링 리스트) — dbus 레퍼런스 구현 신규 안정 브랜치 릴리스 공지로, Meson 전환, ProcessFD, Y2038 안전성 등 주요 변경사항을 설명합니다
• dbus-broker v37 Release Notes (GitHub) — notify-reload 지원, /etc·/run 서비스 탐색, GetStats 확장 등 v37 변경사항입니다
• systemd v258 Release Notes (GitHub) — 서비스 관리자 기본 Varlink API 및 systemd-udevd Varlink 인터페이스 추가 내용을 확인할 수 있습니다
• systemd v259 Release Notes (GitHub) — Varlink 기능 동등성 확장(Reload/Reexecute), systemd-repart/machined/resolved/creds Varlink 추가 내용입니다
• varlink-http-bridge (GitHub) — 로컬 Varlink 서비스를 HTTP로 노출하는 브리지 구현체입니다

관련 문서