Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Mapování z cesty na kontexty pro relabel a kontexty dané přechodovými pravidly by měly být v souladu.
Pokud jste si udělal vlastní adresářovou strukturu, tak byste si měl rozmyslet, jestli kontexty, které dělá apache nedávají smysl. Pokud ano, tak si opravte mapování. Pokud ne, tak si opravte politiku pro apache nebo si nastavte restorecond, aby opravoval kontexty i ve vašich adresářích (nemusí si to ale být zcela bezpečné řešení).
semanage fcontext -l ... /var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0 ... /var/www/html/configuration\.php all files system_u:object_r:httpd_sys_rw_content_t:s0 ...Apache ale vždy vytváří soubory s kontextem httpd_sys_rw_content_t a jediný správný soubor s tímto kontextem je podle mapování /var/www/html/configuration.php. Ovšem né všechny weby mají takové cesty a většinou je potřeba, aby apache zapisoval i jinam ve webovém adresáři. Třeba hostingy si nemůžou toto nastavovat a prostý uživatel nemá oprávnění ke změně mapování. Jak tedy nejlépe řešit konkrétně tuto situaci? Nedá se nastavit mapování pro danou cestu jak na httpd_sys_content_t, tak na httpd_sys_rw_content_t s tím, že se jako výchozí bude uplatňovat to první, ale aby bylo i ten druhý kontext pro tuto cestu správný?
Apache ale vždy vytváří soubory s kontextem httpd_sys_rw_content_t
Protože ten soubor apache vytvořil, tak proč by do něj neměl mít možnost znovu zapsat? Na tomto přechodovém pravidle obecně nevidím nic špatného.
Ovšem né všechny weby mají takové cesty a většinou je potřeba, aby apache zapisoval i jinam ve webovém adresáři.
Pokud to je potřeba, tak si nastavte mapovaní pro dané cesty na httpd_sys_rw_content_t. Z hlavy si nevybavuji všechny apachové kontexty, ale myslím, že tento je správný. Něco se lze dočíst v manuálové stránce httpd_selinux(8).
Třeba hostingy si nemůžou toto nastavovat a prostý uživatel nemá oprávnění ke změně mapování.
Proč by to provozovatel hostingu nemohl nastavovat? Od toho je mapování na kontexty nastavitelné. Samozřejmě že běžný uživatel nemůže měnit nastavit SELinuxu. To by byla bezpečnostní díra.
Jak tedy nejlépe řešit konkrétně tuto situaci?
Konfigurovat SELinux podle požadavků zákazníka (vždyť si to platí), nebo na celý DocumentRoot hodit httpd_sys_rw_content_t. Musíte rozhodnout sám, jestli to chcete mít pohodlné nebo bezpečné.
Nedá se nastavit mapování pro danou cestu jak na httpd_sys_content_t, tak na httpd_sys_rw_content_t s tím, že se jako výchozí bude uplatňovat to první, ale aby bylo i ten druhý kontext pro tuto cestu správný?
Ne. Soubor může mít nejvýše jeden kontext.
Toto mi právě nešlo do hlavy. Když zakázník nahrává webové aplikace, tak ani většinou netuší, jaká oprávnění tam potřebuje. Proto mi přijde nepraktické pro stovky/tisíce webů upravovat kontexty po každé větší aktualizaci webové aplikace. ... no ještě že nedělám hostingy. Já si jen hostuju cca 3 weby, ale stejně jsem narazil na to, že není možné pořádně uhlídat (respektive dá se to dlouhým zkoumáním zdrojového kódu dané webové aplikace), kam má mít apache rw přístup (např. redakční systémy a jejich rozšiřování pluginy).Konfigurovat SELinux podle požadavků zákazníka (vždyť si to platí), nebo na celý DocumentRoot hodit httpd_sys_rw_content_t. Musíte rozhodnout sám, jestli to chcete mít pohodlné nebo bezpečné.
Ano, napsat pořádnou politiku dá práci. Kromě čtení kódu lze přepnout SELinux do permissive režimu, procvičit aplikaci, a pak podle stížností v protokolu SELinuxu napsat politiku. Dokonce existuje nástroj audit2allow, který vám pomůže politiku vygenerovat.
Ve vašem případě ale stačí řešit zápis a čtení pomocí rozdělení kontextů pro soubory, kam se má číst a kam zapisovat. Z rozumně dokumentované aplikace lze snadno poznat, kam má a kam nemá zapisovat. Takže odhadnout mapování z cest na kontexty by neměl být problém. Samozřejmě záleží, jak daná aplikace vypadá. Mám takové neblahé tušení, že webové aplikace patří k horší půlce softwaru.
Tiskni
Sdílej: