openSUSE Leap 42.2
Gnome Terminal 3.20.2
Mám otevřené okno terminálu. Pokud napíšu následující příkaz:
gnome-terminal
jako uživatel bez oprávnění root úspěšně spustí nový terminál.
Pokud však spustím příkaz jako root, zobrazí se následující chybová zpráva:
Chyba při vytváření proxy serveru pro
org.gnome.Terminal:/org/gnome/Terminal/Factory0:Připojení je
uzavřeno
Pokud se pokusím spustit terminál pomocí dbus-launch gnome-terminal pak to funguje.
Co brání gnome-terminálu příkaz spouštějící terminál jako root? A je dbus-launch přijatelné řešení nebo pravděpodobně způsobí nepředvídatelné problémy (fakt nerozumím tomu, co to dělá)?
Přijatá odpověď:
Vzpomeňte si, jak aplikace pro Windows fungovaly hlavně v době 16 dnů před Win32, než se objevil Win32 a zmizel:tam, kde byly hInstance a hPrevInstance , při pokusu o spuštění druhé instance mnoha aplikací se věci jednoduše předaly první instanci, a to zkomplikovalo práci nástrojům pro skriptování příkazů (jako je Take Command), protože člověk by vyvolal aplikaci podruhé, viditelně by tam byla na obrazovka jako přidané okno, ale pokud jde o interpret příkazů, podřízený proces, který právě spustil, okamžitě skončil?
GNOME přineslo zpět chování Win16 pro Linux.
Terminál GNOME je nyní aplikací klient-server. gnome-terminál program je pouze klient, který vytváří zprávy Desktop Bus na server, předává možnosti příkazového řádku, prostředí, pracovní adresář a argumenty a pak jednoduše končí. Server je gnome-terminal-server který se registruje jako org.gnome.Terminal na sběrnici Desktop Bus a která je zodpovědná za veškerou skutečnou emulaci terminálu a zobrazení oken na GUI.
Klient Desktop Bus jako gnome-terminal vyhledá zprostředkovatele Desktop Bus prostřednictvím proměnné prostředí, která obvykle ukazuje na soket v adresáři pro uživatele, jako je /run/user/1001 . Alternativně proměnná prostředí určuje, že se má hledat v „současném uživatelově běhovém adresáři“ a cesta podobná výše uvedené je vytvořena z efektivního ID uživatele klientského procesu. Tento adresář je v obou případech konvenčně soukromý pro jednotlivého uživatele a nepřístupný ostatním (neprivilegovaným) uživatelům.
Veselost nastane, když se lidé pokusí spustit gnome-terminal jako jiný uživatel pomocí sudo a podobně. Pokud proměnná prostředí ukazuje na explicitně pojmenovaný adresář běhového prostředí, neprivilegovaný klient se nemůže připojit ke sběrnici plochy pro jednotlivé uživatele. Pokud proměnná prostředí ukazuje na runtime adresář „aktuálního uživatele“, hledá nesprávného zprostředkovatele Desktop Bus, často toho, kterého uživatel aktuálně nemá spuštěný zprostředkovatel Desktop Bus, protože se uživatel nepřihlásil a nespustil služby pro jednotlivé uživatele daného uživatelského účtu. (Per-user Desktop Bus brokery jsou provozovány správcem služeb pro uživatele. Správce služeb pro uživatele se spouští buď explicitně, nebo v případě některých softwarů pro správu služeb některými poněkud ošklivými háčky v procesu ověřování uživatele, který používá jako přihlášení , su a programy serveru SSH.)
Důvod, proč dbus-launch pro vás jako superuživatele fungovalo to dbus-launch explicitně spustil jiného zprostředkovatele Desktop Bus, běžícího jako superuživatel, který gnome-terminal dokázal mluvit. Naštěstí byl systém také nakonfigurován tak, aby na vyžádání spouštěl gnome-terminal-server server, když se k němu klient pokusil připojit prostřednictvím brokera. (Nemusí to tak nutně být a v dnešní době je takové spouštění poptávky považováno za podřadný mechanismus, protože končí spoustou procesů serveru Desktop Bus, které neběží pod žádným druhem správy služeb. Ve skutečnosti, bez samotného zprostředkovatele Správa služeb je také považována za podřadnou. Také se obecně nepovažuje za dobrý nápad pro superuživatele účtu mít spuštěny tyto druhy služeb, protože mnoho z nich neočekává, že budou spuštěny s oprávněními superuživatele, protože očekávají, že budou spuštěny pod ochranou běžných uživatelských účtů.)
Další veselí nastává, když jako tazatel na téma „Jak mohu spustit gnome-terminál vzdáleně na svém bezhlavém serveru? (nedaří se spustit přes předávání X11)“, lidé se pokusí spustit gnome-terminal když ani původní uživatel nemá spuštěného zprostředkovatele Desktop Bus. K tomu dochází, když se například někdo přihlásí přes SSH, ale proces přihlášení SSH nespustí správce služeb pro jednotlivé uživatele, což zase znamená, že není spuštěn zprostředkovatel Desktop Bus pro jednotlivé uživatele a gnome-terminal-server server není dostupný přes Desktop Bus. (Podle toho, jak je systém nakonfigurován, by grafické přihlášení mohlo stále spouštět spuštění správce služeb pro jednotlivé uživatele, a proto lze pozorovat, že přihlášení graficky jako stejný uživatel magicky věci funguje. A znovu dbus-launch by explicitně spustilo zprostředkovatele Desktop Bus, který není spravován službou.)
Ještě větší zábava nastává, když má jeden ze správců služeb, který má háčky na přihlášení , su a server SSH. Tyto háčky obvykle implementují sémantiku spouštění správy služeb pro uživatele a všech služeb pro uživatele, které spouští, při prvním přihlášení daného uživatele; a zastavit je všechny při posledním odhlášení daného uživatele. Pokud má člověk mnoho krátkodobých a nepřekrývajících se relací SSH, pak může vzniknout spousta režijních nákladů, které se zbytečně spouštějí a vypínají celý systém správy služeb pro jednotlivé uživatele (a všechny jeho služby s automatickým spouštěním) na začátky a konce každé z těchto relací SSH. systemd, jeden takový správce služeb, má nedokonalý mechanismus „zdržování“, který to řeší jen z poloviny. Znamená to, že správa služeb pro uživatele „zdržuje“ po posledním odhlášení, ale spuštění správy služeb pro uživatele to vůbec nezabrání.
Další čtení
- Jonathan de Boyne Pollard (2016).
/run/user/jim/dbus. "Věstník". průvodce nosem . Software. jdebp.eu. - Jonathan de Boyne Pollard (2016). „služby pro uživatele“. průvodce nosem . Software. jdebp.eu.
- Spouštějte skutečné vícenásobné instance procesu gnome-terminal
- Zajistěte trvalou službu systemd uživatele
- https://unix.stackexchange.com/a/323700/5132