Linux डेस्कटॉप में D-Bus की समस्याएँ

 (blog.vaxry.net)
1 पॉइंट द्वारा GN⁺ 2025-12-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • D-Bus ऐप्लिकेशनों के बीच संचार के लिए एक bus है, जिसका कॉन्सेप्ट उपयोगी है, लेकिन इसका implementation बहुत कमजोर और non-standard है
  • standard documentation अधूरी और असंगत है, और वास्तविक implementations इसका पालन नहीं करतीं, जिससे compatibility का ढहना होता है
  • security flaws भी गंभीर हैं; unlock होने की स्थिति में एक ऐप दूसरे ऐप के secret data को पढ़ सकता है
  • इसके जवाब में लेखक नया bus system ‘hyprtavern’ और protocol ‘hyprwire’ विकसित कर रहा है
  • hyprtavern सख्त type checking, built-in permission management, सुरक्षित secret store (kv) आदि के जरिए D-Bus की संरचनात्मक समस्याओं को हल करने की कोशिश करता है

D-Bus की अवधारणा और सीमाएँ

  • D-Bus एक ऐसा सिस्टम है जिसमें application और service shared bus के जरिए methods और properties expose कर सकते हैं और एक-दूसरे को call कर सकते हैं
    • उदाहरण के लिए, यदि मौसम सेवा देने वाला कोई ऐप bus पर API register करता है, तो दूसरे ऐप उसे खोजकर इस्तेमाल कर सकते हैं
  • लेकिन D-Bus की बहुत ढीली और असंरचित design के कारण कोई भी object मनमाने method register और call कर सकता है
    • इससे “Garbage in, garbage out” जैसी स्थिति पैदा होती है

standard documentation और implementation में भ्रम

  • D-Bus की standard documentation कई जगह बिखरी हुई है और अधूरी व कठिन रूप में मौजूद है
    • वास्तविक implementations या तो इसका पालन नहीं करतीं, या अलग-अलग spec को मनमाने ढंग से अपनाती हैं
  • लेखक बताता है कि xdg-desktop-portal-hyprland विकसित करते समय उसने “restore_token” spec implement किया,
    लेकिन सभी ऐप अनौपचारिक “restore_data” field का उपयोग कर रहे थे, इसलिए compatibility नहीं बनी
  • D-Bus का variant type (a{sv}) मनमाना data transfer करने देता है, और इसे protocol consistency तोड़ने का बड़ा कारण बताया गया है

security संरचना की खामियाँ

  • D-Bus में centralized permission management या deny mechanism मौजूद नहीं है
    • सभी ऐप दूसरे ऐप की calls देख सकते हैं, और यदि कोई explicit security mechanism न हो तो असीमित access संभव है
  • gnome-keyring, kwallet जैसे secret stores भी संरचनात्मक रूप से कमजोर हैं
    • store unlock होने पर हर ऐप सभी secret data तक पहुँच सकता है
    • लेखक ने इसे “security joke के स्तर” का बताया

नया विकल्प: hyprwire और hyprtavern

  • लेखक D-Bus की समस्याओं को हल करने के लिए नया bus system ‘hyprtavern’ विकसित कर रहा है
    • hyprwire Wayland के design से प्रेरित एक सरल और सुसंगत wire protocol है
      • इसकी खासियतें हैं type enforcement, तेज connection, और सरल संरचना
    • hyprtavern की संरचना ऐसी है जिसमें ऐप protocol-आधारित objects register करते हैं और एक-दूसरे को खोजते हैं
      • यह built-in permission system, सख्त protocol compliance, सरल API, और secure defaults देता है

hyprtavern-kv (सुरक्षित key-value store)

  • यह D-Bus की Secrets API को replace करने वाला core protocol है
    • किसी ऐप द्वारा register किए गए secrets को सिर्फ वही ऐप पढ़ सकता है, और उनका enumeration संभव नहीं है
    • Flatpak, Snap, AppImage ऐप्स के लिए ID-आधारित access control की भी योजना है
    • data हमेशा encrypted रूप में store होगा, और password सेट होने पर वास्तविक security guarantee संभव है
    • सभी ऐप सुरक्षित secret storage feature को डिफ़ॉल्ट रूप से इस्तेमाल कर सकेंगे

development status और आगे की योजना

  • hyprtavern अभी development के शुरुआती चरण में है, और आगे Hyprland 0.54 version में इसका आंतरिक उपयोग किया जाएगा
  • शुरुआती adoption सीमित रहने की उम्मीद है, लेकिन क्रमिक transition संभव है
    • D-Bus के विपरीत, कई session buses को साथ चलाया जा सकता है, इसलिए compatibility proxy लिखना भी संभव है
  • यह C++ में लिखा गया है, और Rust·Go·Python bindings भी आसानी से implement किए जा सकते हैं
  • लेखक ज़ोर देकर कहता है कि “D-Bus को मूल रूप से ठीक नहीं किया जा सकता; इसे पूरी तरह नए सिरे से design करना होगा”

FAQ सारांश

  • “पहिया फिर से बनाने” वाली आलोचना पर लेखक कहता है कि D-Bus की मूल design ही टूटी हुई है, इसलिए redesign अपरिहार्य है
  • documentation अभी WIP (कार्य प्रगति पर) है और पूरा होने के बाद जारी किया जाएगा
  • Wayland का उपयोग न करने का कारण यह है कि वह सामान्य IPC उपयोग के लिए उपयुक्त नहीं है
  • D-Bus compatibility proxy (hyprtavern-dbus-notification-proxy) लिखना संभव है
  • Rust की जगह C++ चुनने का कारण यह है कि developer की मुख्य भाषा C++ है
  • security के लिहाज़ से LD_PRELOAD attack को पूरी तरह रोकना कठिन है, लेकिन यह संरचना हमले की कठिनाई और detectability बढ़ाती है

निष्कर्ष

  • D-Bus को non-standard, insecure, और inconsistent होने के कारण Linux डेस्कटॉप ecosystem की bottleneck के रूप में देखा जा रहा है
  • hyprtavern को इसके स्थान पर एक आधुनिक और सुरक्षित IPC bus के रूप में विकसित किया जा रहा है,
    और Hyprland ecosystem के केंद्र में क्रमिक अपनाने की उम्मीद है
  • लक्ष्य है “userspace को अधिक आरामदायक बनाना”

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-12-17
Hacker News टिप्पणियाँ

  • GNOME के secret storage access vulnerability विवाद को देखकर, यह मज़ेदार लगता है कि GNOME टीम ने “untrusted apps secret service से communicate नहीं कर सकतीं” वाले security model के आधार पर समस्या से इनकार किया
    GNOME सच में किसी joker troupe द्वारा चलाया जाने वाला project लगता है

    • Wayland security के नाम पर input event interception को रोकता है, लेकिन ऐसी समस्याएँ वैसे ही छोड़ देता है, यह विडंबनापूर्ण है
    • मैं secret storage को बस “ऐसा data जिसे disk पर plaintext में store नहीं करना चाहिए” के रूप में देखता था। अगर apps के बीच isolation चाहिए, तो virtual machine इस्तेमाल करना सही है
    • user privileges पर चलने वाले programs का उसी user के data तक पहुँच पाना स्वाभाविक है। अगर वही vulnerability है, तो पूरा Linux ही टूट चुका माना जाएगा। इस संदर्भ में xkcd 1200 बिल्कुल सटीक उपमा है
    • आखिरकार मामला शायद “intended behavior, won’t fix, discussion locked” पर खत्म होगा
    • आजकल AI की बदौलत सारा code cloud में फेंककर सीधे audit किया जा सकता है, तो अब सब लोग सिर्फ भरोसेमंद software ही इस्तेमाल कर सकते हैं /s

  • किसी ने कहा कि वह “खुद एक नया bus बनाएगा”, तो मैंने सुझाव दिया कि पहले से अरबों devices पर deployed Binder को reuse क्यों न किया जाए
    Binder Android का core IPC है, और इसके पीछे कहीं ज़्यादा developers और battle-tested code है

    • Binder के ऊपर नया system बनाने से कहीं ज़्यादा robust foundation मिल सकता है। ऊपर से Google ने हाल ही में Rust में kernel Binder implement करके merge भी कर दिया है
      संबंधित लेख: LWN, Rust-for-Linux mailing
    • लेकिन Android के बाहर Binder user-space implementations लगभग नहीं हैं
    • मैंने “BSD Binder” या “Windows Binder” खोजकर देखा, लेकिन कुछ नहीं मिला। शायद “serious OS” वाली बात मज़ाक रही होगी
    • जानना चाहूँगा कि Binder, D-Bus से बेहतर है या नहीं। किस मायने में यह बेहतर है, यह समझना है
    • हो सकता है किसी दिन Linux desktop में भी Binder आ जाए। Android के साथ

  • Hyprwire और Hyprtavern से उम्मीद थी, लेकिन documentation या tests लगभग नहीं हैं
    अफ़सोस है कि ऐसे projects एक अच्छा starting point बन सकते थे

    • शायद developer अभी university graduation exam period में है
    • पोस्ट में भी कई बार कहा गया है कि “अभी तैयारी चल रही है”, इसलिए पूरा होने के बाद देखूँगा

  • OpenWrt developers ने बहुत पहले ही ubus नाम का एक alternative बना लिया था
    संदर्भ: ubus docs, ubus vs dbus comparison
    लेकिन इसका security model लगभग न के बराबर है, और OpenWrt की प्रकृति देखते हुए इसकी वजह समझ में आती है

  • D-Bus की समस्याओं में से एक browser extensions से जुड़ी vulnerabilities हैं, जो GNOME/KDE के साथ communicate करते समय पैदा होती हैं
    सिर्फ website visit करने भर से D-Bus API flood होकर desktop hang हो सकता था
    अगर आप security researcher हैं, तो D-Bus वास्तव में तलाशने लायक क्षेत्र है

    • यह जानना चाहूँगा कि “website का GNOME या KDE के साथ integrate होना” आखिर मतलब क्या है
    • ऐसी समस्याएँ independent VM environment में नहीं होतीं

  • D-Bus Linux desktop में XPC, COM, Android IPC जैसी चीज़ों के सबसे क़रीब है
    लेकिन desktop fragmentation की वजह से एक unified development stack बनाना मुश्किल है
    GNOME के लिए बनाई गई चीज़ KDE में बेकार हो जाती है, और XFCE या Sway तो अलग ही चलते हैं

    • KDE पहले DCOP नाम का अपना IPC इस्तेमाल करता था, लेकिन अब उसे D-Bus से replace कर दिया गया है
    • D-Bus को 20 साल से ज़्यादा हो चुके हैं, इसलिए अब शायद reboot की ज़रूरत है। लेकिन कोई नया IPC सफल होने के लिए technology से ज़्यादा social influence माँगता है
    • KDE में COM जैसा KParts भी था
    • fragmentation आखिरकार अलग-अलग use cases के मौजूद होने का स्वाभाविक परिणाम है

  • अब जाकर पता चला कि KWallet या GNOME Keyring जैसे secret stores, unlock होने के बाद लगभग सभी apps के लिए accessible होते हैं
    seahorse GUI में देखकर लगा कि ज़्यादातर Chromium-related keys या JetBrains account tokens ही थे
    plaintext passwords तो नहीं थे, लेकिन लगा कि अगर कोई malicious app Chromium data खंगाले, तो शायद कुछ और भी निकल सकता है

    • अगर आप password टाइप नहीं कर रहे, तो वह memory में plaintext के रूप में मौजूद होगा ही
      अगर system access के समय notification नहीं देता, तो कौन सा software उसे manage कर रहा है, इससे ज़्यादा फ़र्क नहीं पड़ता

  • सवाल है कि आखिर general-purpose bus protocol की ज़रूरत ही क्यों है?
    Unix domain socket पर HTTP या simple JSON protocol इस्तेमाल करना काफ़ी होना चाहिए
    permissions, SSH forwarding, container mounts जैसी चीज़ें भी सब support हो जाती हैं
    D-Bus में service, interface, path, method जैसी संरचनाएँ काफ़ी जटिल हैं, फिर भी message identification अधूरा है, और app-specific protocol details भी जाननी पड़ती हैं
    आखिरकार proxy handling भी मुश्किल हो जाती है, और यह system ज़रूरत से ज़्यादा complex है

  • D-Bus का design इस law of randomness का उदाहरण लगता है कि “सबसे बेहतरीन solution ज़रूरी नहीं चुना ही जाए”
    जैसे React से बेहतर frameworks अनगिनत हैं, लेकिन जाने नहीं गए तो दब गए

    • अक्सर ऐसा इसलिए होता है क्योंकि लोग समस्या को पूरी तरह समझे बिना उसका मूल्यांकन कर देते हैं
    • D-Bus के चल निकलने में GNOME और Red Hat connection की बड़ी भूमिका थी
    • सच तो यह है कि “सबसे बेहतरीन” जैसा कोई हल होता ही नहीं, सब अलग-अलग tradeoff space में होते हैं। दूसरों की मेहनत को यूँ ही खारिज करने वाले रवैये से बचना चाहिए
    • open source का बड़ा हिस्सा volunteers बनाते हैं। कुछ लोग हज़ारों घंटे लगाकर development करते हैं, इसलिए दिशा वही तय करें, यह स्वाभाविक है। ऐसे ढाँचे में अजीब फैसले भी होना तय है
    • “worse is better” की तरह, हक़ीक़त यह है कि selection process खुद अक्सर सबसे inefficent तरीके से होता है

  • GNOME ने vulnerability report का खंडन करते हुए Flatpak sandbox access restrictions का ज़िक्र किया, तो पुराने Microsoft blog post की याद आ गई
    ऊपर से quotation को सिर्फ screenshot के रूप में डालना ताकि उसे copy भी न किया जा सके, यह बिल्कुल समझ से बाहर है

    • Wayland root privileges के बिना screenshots को रोकता है, लेकिन D-Bus YOLO spirit के साथ खुला पड़ा है