abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 01:55 | Nová verze

Byla vydána verze 1.13 multiplatformního open source textového editoru Brackets (Wikipedie, GitHub). Přehled novinek v oficiálním oznámení a v poznámkách k vydání. Brackets je nově dostupný také jako balíček ve formátu Flatpak z oficiálního repozitáře Flathub.

Ladislav Hagara | Komentářů: 0
včera 18:44 | Komunita

Oficiální YouTube kanál Blenderu je již několik dní blokován. Důvody jsou zatím nejasné. Pravděpodobně chyba YouTube. Dění lze sledovat na Twitteru Tona Roosendaala.

Ladislav Hagara | Komentářů: 2
včera 17:55 | Zajímavý software

Na GitHubu byly pod open source licencí LLVM zveřejněny zdrojové kódy překladače programovacího jazyka C++ Zapcc vycházejícího z Clangu/LLVM. Překlad pomocí Zapccu je díky lepšímu kešování obvykle několikrát rychlejší než překlad pomocí Clangu. V březnu loňského roku byl vydán Zapcc ve verzi 1.0.

Ladislav Hagara | Komentářů: 0
včera 17:22 | Pozvánky

Červnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 21. 6. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát na téma: F-Droid, aneb svobodný software do vašeho mobilu. Kromě toho budou k vidění i vývojové desky HiFive1 se svobodným/otevřeným čipem RISC-V.

xkucf03 | Komentářů: 0
15.6. 22:44 | Zajímavý článek

Na blogu projektu NeoPG (GitHub), kryptografického softwaru vycházejícího z GnuPG, byly zveřejněny 4 příspěvky detailně popisující aktuální bezpečnostní problémy v GnuPG a souvisejících softwarových produktech. V prvním příspěvku je ukázáno, že je možné vytvořit zprávu, o které budou Earlybird, Evolution, Mutt nebo Outlook tvrdit, že jí dešifrovali a přitom ale zpráva vůbec zašifrována nebyla. V druhém příspěvku je popsána

… více »
Ladislav Hagara | Komentářů: 6
15.6. 13:00 | Komunita

GamingOnLinux informuje, že počítačová hra Track Mania Nations Forever (Steam, Wikipedie) pro Windows je nově dostupná také jako snap. Stejně jako v případě winepaku a Flatpaku se k běhu hry používá překladová vrstva Wine.

Ladislav Hagara | Komentářů: 12
14.6. 15:12 | Komunita

Tradiční setkání příznivců operačního systému Linux pod názvem Linux párty Teplice se bude konat v pátek 15. 6. 2018 v Hospůdce u černé Kočky od 18:00 hodin. Setkají se zde pamětníci příkazové řádky, vítáni jsou však i začínající uživatelé.

František Bublík | Komentářů: 21
14.6. 14:00 | Bezpečnostní upozornění

Intel potvrdil (INTEL-SA-00145) další bezpečnostní chybu ve svých procesorech. Jedná se o chybu CVE-2018-3665 s názvem LazyFP.

Ladislav Hagara | Komentářů: 13
14.6. 11:00 | Nová verze

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 153. brněnský sraz, který proběhne v pátek 15. června od 18:00 v restauraci U OSLŮ na ulici Sokolská 361/10. Pro zájemce proběhne krátké promítání z výletu do Černobylu.

Ladislav Hagara | Komentářů: 0
13.6. 19:58 | Upozornění

Server lupa.cz rozebírá připravovanou reformu copyrightu v EU a dopad jejího článku 13, který dává internetovým platformám povinnost řešit autorské právo za vlastníky práv, což by v podstatě vedlo k automatizované cenzuře a konci internetu tak, jak ho známe dnes. Podobně v otevřeném dopise varují Vint Cerf, Tim Berners-Lee a jiní odborníci, Cory Doctorow upozorňuje na důsledky pro Wikipedii, nebo github na sdílení kódu.

marbu | Komentářů: 106
Jak čtete delší texty z webových stránek?
 (78%)
 (22%)
 (4%)
 (7%)
 (2%)
 (11%)
Celkem 204 hlasů
 Komentářů: 36, poslední včera 21:16
    Rozcestník

    Vzdálený přístup

    Protokol X11 je navržen tak, aby ho bylo možné používat nejen tehdy, když X server a klientská aplikace běží na témže počítači, ale i v případě, že běží na různých počítačích, které jsou propojeny sítí. V takovém případě je ke komunikaci využíváno TCP spojení. Aby mohla aplikace komunikovat s X serverem, je třeba jí sdělit, na který X server (a případně na kterou obrazovku) má zobrazovat. Tato informace je obvykle předávána prostřednictvím proměnné prostředí DISPLAY, klasické grafické programy podporují i parametr příkazové řádky -display (nebo zkráceně -disp).

    Hodnota proměnné (resp. argument) má obecně tvar 'host:display.screen'. Nepovinný parametr host definuje počítač, kde se X server nachází. Většinou obsahuje jméno počítače nebo IP (IPv4 nebo IPv6) adresu. Není-li uveden, kontaktuje se X server na stejném počítači, většinou ale ne pomocí TCP spojení přes lokální smyčku, ale přes lokální (unix domain) socket.

    Parametr display určuje číslo konkrétního X serveru na zvoleném počítači. Na jednom počítači může totiž X serverů běžet více, například je-li současně otevřeno více grafických konzolí. Jiným příkladem je spuštění programu Xnest, který implementuje X server používající jako virtuální obrazovku okno zobrazované na jiném X serveru. Obvyklé číslování X serverů je od nuly, nejčastěji se zde proto setkáme s hodnotou 0. Tento parametr je také (včetně dvojtečky) jediný povinný, minimální (a také nejčastější) specifikace obrazovky je tedy ':0'. Z praktického hlediska parametr display při TCP komunikaci určuje port, na nějž je navazováno spojení; jedná se o port 6000+display.

    Poslední (opět nepovinný) parametr screen určuje obrazovku, na kterou má aplikace zobrazovat. Obrazovky (má-li jich X server více) se číslují opět od nuly (nula je i defaultní hodnotou). Číslo obrazovky na rozdíl od předchozích parametrů neovlivňuje navázané spojení, informace je používána interně v rámci komunikace protokolem X11. Obrazovky v tomto smyslu nemají nic společného s virtuálními pracovními plochami, které nabízí většina window managerů. Nejčastěji se s více obrazovkami setkáváme u počítačů s více monitory, kde číslo obrazovky určuje (fyzický) monitor, na který bude aplikace zobrazovat.

    Praktická použitelnost aplikace běžící na vzdáleném počítači a zobrazující na lokální X server je ovlivněna parametry síťového spojení. Je-li spojení realizováno lokální sítí, nebývá to problém; u 100 Mb/s ethernetu na chování většiny aplikací není vzdálená komunikace příliš znát. U pomalejších spojení (kromě přenosové rychlosti zde hraje roli i zpoždění paketů) jsou pochopitelně odezvy delší. Hodně zde záleží i na tom, co aplikace zobrazuje. Vykreslování jednoduchých objektů nebo vypisování textů není příliš náročné, ale např. při prohlížení fotografií je třeba přenášet celé bitmapy, což může být poměrně náročné. Nezanedbatelnou výhodou je i skutečnost, že tímto způsobem můžeme používat grafické aplikace i na počítači, kde není vůbec nainstalován X server, např. na výkonném aplikačním serveru, ke kterému přistupují uživatelé ze svých pracovních stanic. Nelze zapomínat ani na to, že protokol je univerzální: není tedy omezen na prostředí Linuxu, ale lze jej používat i mezi různými platformami.

    Možnost zobrazování na X prostřednictvím TCP/IP sítí (a tedy i Internetu) je velmi užitečným nástrojem, jedná se ale o dvousečnou zbraň. Pokud bychom neaplikovali mechanismus, který by omezil potenciální klienty, mohl by kdokoli používat náš X server, a to nejen k zobrazování, ale i k získávání událostí od vstupních zařízení; mohl by tedy mimo jiné např. sledovat, co píšeme na klávesnici. Nepotřebujeme-li vůbec přistupovat na X server vzdáleně, může být vhodnější použít při jeho spouštění parametr '-nolisten tcp', který způsobí, že X server nebude vůbec poslouchat na TCP portu 6000+display a umožní pouze komunikaci lokálních klientů přes lokální socket. Některé novější distribuce naopak spouštějí X server s tímto parametrem defaultně, takže naopak chceme-li komunikovat vzdáleně, je potřeba to explicitně povolit. V dalších částech se ale zaměříme na situaci, kdy vzdáleně komunikovat chceme, ale potřebujeme klienty autorizovat.

    Seznam povolených adres

    Nejjednodušší formou autorizace je rozlišení klientů podle IP adresy. Display manager udržuje seznam adres (standardně prázdný), z nichž je povolen přístup všem klientům bez dalších omezení. K manipulaci s tímto seznamem lze použít příkaz xhost, bez parametrů vypíše seznam povolených adres (standardně přeložených na DNS jména). Přidání položky do seznamu lze provést příkazem 'xhost +host' (znak + lze vynechat), odebrání příkazem 'xhost -host'.

    Jak už to bývá, je tato varianta sice nejjednodušší, ale také nejméně vhodná. Jednak povolením adresy konkrétního počítače povolujeme přístup automaticky všem jeho uživatelům, jednak při podvržení IP adresy server nepozná, že se nejedná o oprávněného klienta. Pomineme-li tedy specifické případy typu lokální sítě o dvou počítačích a jednom uživateli. nelze tuto metodu v dnešní době pro praxi doporučit.

    Autentizační cookies

    Při spuštění seance (session) display manager generuje náhodný klíč (cookie), který je s touto seancí svázán. Klient, který se prokáže znalostí této cookie, má povolen přístup k X serveru, aniž by jeho IP adresa musela být v seznamu z předchozí sekce. Cookie je spolu s informací o serveru (zapisuje se ve stejném formátu jako hodnota proměnné DISPLAY s vynecháním čísla obrazovky) uložena do autentizační databáze, která je standardně v souboru .Xauthority v domácím adresáři přihlášeného uživatele. Z tohoto souboru si pak cookies berou jednotlivé grafické aplikace a používají je pro autentizaci vůči serveru.

    S obsahem autentizační databáze lze pracovat příkazem xauth, a to buď interaktivně (spustíme-li ho bez parametrů) nebo neinteraktivně (předáme-li mu příkaz přímo jako argument). Základní příkazy jsou:

    Jako jméno souboru lze uvést i znak '-', cookie se pak extrahuje na standardní výstup a načítá se ze standardního vstupu. Pokud v takovém případě nepřesměrováváme výstup nebo nepoužijeme rouru, je vhodnější použít příkazy nextract a nmerge, používající formát složený pouze z číslic, který lze zobrazovat na terminál a kopírovat pomocí selection nebo copy&paste.

    Přihlásíme-li se tedy na vzdálený počítač např. pomocí SSH a chceme-li na něm spouštět grafické aplikace tak, aby zobrazování probíhalo na náš lokální X server, je třeba nastavit odpovídajícím způsobem proměnnou DISPLAY tamnímu shellu (nesmíme ale zapomínat, že shell a posléze i grafická aplikace poběží na vzdáleném počítači, nelze tedy psát localhost nebo jméno počítače vynechat). Dále ale také musíme zkopírovat autentizační cookie z lokální databáze do vzdálené. To lze provést buď extrakcí do souboru, jeho překopírováním a importem cookie do databáze, nebo extrakcí na terminál a překopírováním do druhého okna, kde jsme přihlášeni na vzdáleném stroji a předem jsme použili 'xauth nmerge -'.

    Transparentní tunelování pomocí SSH

    Zásadní nevýhodou předchozích postupů je skutečnost, že řeší pouze otázku autentizace a autorizace (a ani to ne zcela spolehlivě), ale žádným způsobem nechrání data, která si mezi sebou vyměňují X server a klientská aplikace, a to proti odposlechu ani proti podvržení. Pokud tedy komunikace mezi oběma počítači není zabezpečena např. pomocí IPsec, není takové řešení příliš vhodné, a to zejména, komunikují-li mezi sebou přes Internet. Protože X11 komunikace používá jedno TCP spojení, je ideálním kandidátem na zabezpečení pomocí SSL (např. programem stunnel). Protože se ale dnes na vzdálený počítač, kde aplikaci spouštíme, většinou připojujeme pomocí SSH, je jednodušší využít možnosti transparentního tunelování X11 přes jeho zabezpečený přenosový kanál.

    K pochopení toho, jak funguje tunel, je třeba mít na paměti, že X server je na straně, kde je SSH klient, a naopak. Tunelování není třeba nijak složitě nastavovat, pouze je nutné, aby tato funkce byla povolena v konfiguraci klienta (ssh) i serveru (sshd) a aby byl klient spouštěn s parametrem -X a měl nastavenou proměnnou DISPLAY na lokální X server. Je-li tomu tak, SSH démon vytvoří virtuální X server (standardně s číslem od 10 výše, aby nedocházelo ke kolizi s případnými lokálními X servery na jeho straně. Na tento X server (tj. typicky na hodnotu ':10') pak také nastaví shellu (nebo jinému spouštěnému programu) proměnnou DISPLAY.

    Spuštěná grafická aplikace tedy veškeré požadavky posílá na virtuální X server, ten je ale pouze přeposílá (zabezpečeným spojením) SSH klientovi, který je dále předá lokálnímu X serveru na straně uživatele. Podobně, pouze v opačném směru, jsou posílány odpovědi X serveru aplikaci. Aplikace samozřejmě nemusí běžet na stejném počítači jako SSH démon, podobně SSH klient nemusí běžet na stejném počítači jako X server. Pak je ale zabezpečený jen úsek mezi SSH démonem a SSH klientem, to ale může být dostatečné, např. jsou-li koncové úseky realizovány relativně bezpečnou lokální sítí, zatímco tunelovaný úsek vede přes Internet.

    Kromě obvyklých bezpečnostních opatření při používání SSH (zejména kontrola pravosti veřejného klíče serveru při prvním přihlášení) nesmíme zapomínat, že tunel chrání jen před útoky "po cestě". Není tedy ochranou před lokálním útokem na koncových počítačích. Zejména pokud bychom nemohli důvěřovat uživateli root na vzdáleném počítači, zpřístupňujeme mu otevřeným tunelem svůj lokální X server (po dobu, kdy je tunel navázán). Nesmíme také zapomínat, že při větších datových tocích šifrování a autentizace dat zatěžuje procesor obou stran. Naopak, u pomalých spojení lze zapnutím komprese (přepínač -C) přenos urychlit snížením objemu přenášených dat.

    Lokální komunikace pod jiným uživatelem

    Problematika lokální komunikace do této kapitoly zdánlivě nepatří, ale vše, co bylo řečeno v předchozích sekcích, se vztahuje i na aplikace běžící na témže počítači jako X server. Procesy uživatele, který se přihlásil do grafického prostředí, mají samozřejmě přístup k vygenerované cookie, takže jim je přístup umožněn. Pokud ale použijeme příkaz su, nebudou mít procesy spouštěné pod cílovým uživatelem k X serveru povolen přístup.

    Povolení přístupu pomocí 'xhost localhost' není vhodným řešením, protože tím bychom povolili přístup všem lokálním uživatelům a procesům. Řešení pomocí SSH je zase zbytečně náročné, protože šifrování a autentizace jsou při lokální komunikaci zcela zbytečné a pouze by zatěžovaly procesor. Nejvhodnějším řešením je tedy zkopírování autentizační cookie do databáze cílového uživatele. Lze to provést stejným způsobem jako při vzdálené komunikaci, kopírování je zde ale o něco jednodušší. Je-li cílovým uživatelem root, lze navíc využít toho, že má povoleno čtení jakéhokoli souboru ve filesystému a nechat ho extrahovat cookie přímo z databáze přihlášeného uživatele:

      xauth -f ~user/.Xauthority extract - :0 | xauth merge -
    
    (user reprezentuje jméno přihlášeného uživatele).

    Jednodušší alternativou je použití příkazu sux, který funguje podobně jako su, ale navíc automaticky kopíruje autentizační cookie od původního uživatele k novému. Také lze použít autentizační modul pam_xauth, který způsobí automatické předání autentizační cookie při použití příkazu su. Stačí přidat do souboru /etc/pam.d/su řádek

      session  optional       pam_xauth.so
    
    Pomocí konfiguračních souborů ~/.xauth/export a ~/.xauth/import lze pak definovat, kterým uživatelům se mají autentizační cookies předávat (neexistuje-li soubor export, pak normální uživatel předává všem, root nikomu) resp. od koho se mají přijímat (neexistuje-li soubor import, přijímá se od všech).

    XDMCP - Linux jako terminál

    Protože window manager je z pohledu X serveru klientská aplikace jako každá jiná, může samozřejmě i on běžet na jiném počítači než X server. Můžeme pochopitelně spouštět i window manager se zobrazováním na jiný X server pomocí proměnné DISPLAY nebo parametru -display, např.:

      Xnest -geometry 1024x768 :1 &
      fvwm -display :1 &
    
    V praxi je ale vhodnější ponechat proces přihlášení, otevření seance a případnou volbu window manageru (a další konfigurace) na display manageru (xdm, kdm, gdm, wdm) počítače, ke kterému se přihlašujeme. Počítač, u něhož uživatel sedí, je pak vlastně degradován do role klasického X terminálu, na němž se zobrazí přihlašovací obrazovka vzdáleného počítače. Komunikace mezi X serverem a vzdáleným display managerem je realizována protokolem XDMCP (X Display Manager Control Protocol), standardně je pro něj používán UDP port 177.

    Chceme-li se takto přihlásit ke vzdálenému počítači, je třeba při spouštění X serveru tento počítač specifikovat parametrem -query (argumentem je jméno nebo IP adresa):

      X -query 192.168.2.65
    
    Místo lokálního přihlašovacího okna se objeví přihlašovací okno nebo obrazovka vzdáleného display manageru. Po přihlášení je spuštěn (na vzdáleném počítači) odpovídající window manager podle tamní konfigurace.

    Chceme-li, aby náš počítač fungoval jako terminál pro více vzdálených stanic, můžeme spustit display manager (konkrétní nastavení závisí na volbě display manageru) v režimu, kdy je uživateli místo lokálního přihlašovacího dialogu nejprve zobrazen seznam počítačů, na které se může přihlásit, a teprve poté, co si ze seznamu vybere cílovou stanici, je zobrazen její přihlašovací dialog (obrazovka). Seznam může být buď definován staticky v konfiguraci lokálního display manageru nebo může být vytvářen dynamicky. Ve druhém případě display manager rozešle broadcast datagram s dotazem, kdo je ochoten povolit přihlášení, a zobrazí se seznam stanic, které odpověděly. Tento seznam se pak obvykle periodicky aktualizuje. Je možná i kombinace staticky konfigurovaného a dynamicky generovaného seznamu.

    XDMCP protokol neobsahuje prakticky žádné bezpečnostní prvky a vzhledem k použití UDP není ani jeho dodatečné zabezpečení příliš snadné. Jeho použitelnost je proto omezena prakticky jen na důvěryhodné lokální sítě, kde se používá pro klasické X terminály a tenké klienty. Samozřejmě i použití XDMCP podléhá konfiguraci autorizačních pravidel, ale jejich výklad by byl nad rámec tohoto letmého seznámení. Bližší informace lze získat např. z těchto zdrojů:

    Dokument vytvořil: vladka, 29.8.2005 12:09 | Poslední úprava: Nicky726, 11.3.2009 23:55 | Další přispěvatelé: Michal Kubeček, Milan Horák | Historie změn | Zobrazeno: 9323×

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.