Ezoterický programovací jazyk Brainfuck (Wikipedie) slaví 30 let. Urban Müller nahrál první implementaci tohoto jazyka na Aminet 9. června 1993.
Společnost Apple na konferenci WWDC23 představila Game Porting Toolkit. Společnost CodeWeavers informuje, tento toolkit vychází ze zdrojových kódů jejího CrossOveru, tj. komerčního Wine.
Byla vydána květnová aktualizace aneb nová verze 1.79 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.79 vyšlo také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Jak to bude s podporou rastrového grafického formátu JPEG XL ve webových prohlížečích? Google ji nedávno z Chrome a Chromia odstranil (#1178058#c84). Jednou z novinek beta verze Safari 17 je ale právě podpora JPEG XL. Vráti se JPEG XL do Chrome a Chromia (#1451807)? Dění kolem JPEG XL lze sledovat například na r/jpegxl.
Byla vydána nová stabilní verze 6.1 (aktuálně 6.1.3035.51) webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 114. Přehled novinek i s náhledy v příspěvku na blogu. Nový Vivaldi se pro Bing tváří jako Microsoft Edge (upravený User-Agent) a díky tomu v něm funguje Bing Chat. Vylepšeny byly Pracovní prostory (Workspaces). Podrobný přehled v Changelogu.
Linuxová distribuce ArchLabs Linux po šesti letech vývoje končí. Dobbie to zabalil.
David Tschumperlé v obšírném článku se spoustou náhledů shrnuje vývoj multiplatformního svobodného frameworku pro zpracování obrazu G'MIC (GREYC's Magic for Image Computing, Wikipedie) za poslední rok a půl.
Vývojáři postmarketOS vydali verzi 23.06 tohoto před šesti lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell, Phosh, Plasma a Sxmo. Aktuálně podporovaných zařízení je 30.
Byla vydána distribuce openSUSE Leap verze 15.5 (poznámky k vydání). Jde o konzervativní distribuci odpovídající komerčnímu SUSE Linux Enterprise 15, nyní Service Pack 5. Mělo jít o poslední aktualizaci Leap v současné podobě před přechodem na Adaptable Linux Platform s „neměnným“ základem, ale padlo rozhodnutí, že v roce 2024 ještě vyjde Leap 15.6 s podporou do konce roku 2025.
Alyssa Rosenzweig v příspěvku na blogu oznámila, že Asahi Linux už zvládá OpenGL 3.1. Dokončuje se podpora OpenGL ES 3.1. Dalším krokem bude Vulkan 1.0.
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: