Vládní CERT upozorňuje na kritickou zranitelnost v GitLab Community Edition (CE) a Enterprise Edition (EE). Zranitelnost CVE-2026-85706 typu path traversal v Repository Commits API dosahuje skóre CVSS 10.0. Kvůli nedostatečnému omezení cest a chybějícímu vynucení autentizace může za určitých podmínek neautentizovaný útočník číst libovolné soubory ze serveru GitLab, a získat tak přístup k citlivým datům a konfiguraci instance.
Linux může běžet nativně na ESP32-S3 – bez emulace a rovnou s 9,7″ e-paperem.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 7.0.0. Pro sandboxing se na Linuxu nově používá Landlock místo Bubblewrap. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Správce fotografií Shotwell byl vydán ve verzi 33.0 (GitLab). Hlavní novinkou v tomto vydání po dvou letech je přechod na GTK4.
Na YouTube byly publikovány videozáznamy přednášek a na Flickru fotografie z konference EuroPython 2026.
Byl vydán Debian 13.7, tj. sedmá opravná verze Debianu 13 s kódovým názvem Trixie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Jiří Eischmann se v příspěvku Fiasko jménem W Social na svém blogu věnuje evropské sociální síti W: "W Social je příkladem toho, že se problémy sociální sítí nedají řešit od exekutivního stolu. Když na začátku tohoto roku v Davosu oznámili vznik nové sociální sítě W Social, politici se mohli přetrhnout ve chvalozpěvech. Konečně evropská sociální síť a ještě s ověřením identity. … Jak se ukázalo, když v Davosu W Social oznamovali, neměli kromě
… více »Výrobce hardwarových kryptoměnových peněženek Trezor upozorňuje na bezpečnostní incident u společnosti Brevo, kterou využívá k odesílání newsletterů. Útočník na e-mailové adresy odeslal phishingový e-mail.
Clement "Clem" Lefebvre publikoval souhrn dění v Linux Mintu za srpen 2026. Aplikace XApp mají vlastní webovou stránku xapp-project.org. Představena byl čtečka EPUB s názvem Xepub a kalendář Clockenstein.
Byla vydána nová verze 3.2.6 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Na svem serveru jsem se rozhod provozovat apache2 v chrootu (proste projistotu). Dokonce jsem si kvuli tomu zprovoznil na notebooku vmware a v nem takovy pokusny stroj, ze to nejdriv vyzkousim na nem a pak teprve naostro na serveru.
Jak jsem postupoval? Jednoduse, "apt-cache search chroot" a "apt-cache search jail", a procist si o projektech. Nakonec jsem si procet a vyzkousel 2, jailer a makejail.
Jailer jsem i rozchodil, ale moc mi nevyhovoval - sice sam zprovoznil apache2 v jailu (a to tim ze se kouknul do .deb balicku apache2 ana zavislosti a vsechny soubory ktery jsou potreba a ty nakopiroval do chrootu), ale byl tu malinkej hacek. V navodu je napsano "nedelejte zadne zmeny uvnitr chrootu, pri update chrootu (napr. po update balicku apache) byste o ne prisli. Delejte zmeny mimo chroot a nechte jailer zmeny promitnout do chrootu. To se hezky rekne, ale tezko udela. Kdybych si v apache rozchodil twiki, musel bych pred update chrootu vsechny prispevky nakopirovat mimo chroot, abych o ne neprisel. Takze jailer zamitnut
makejail - programek v pythonu, ktery na to jde jinak. Spusti program ktery je definovany v konfiguraku, a pres strace kouka co se snazi otevrit, a nakopiruje mu to do chrootu. To opakuje tak dlouho az je program spokojen. Chvili jsem si s tim hral, a malem jsem to i zprovoznil
Nakonec jsem si ale vzpomnel ze jsem videl neco jako "mod_chroot" do apache1.3, a tak jsem zkusil hledat "mod_chroot" pro apache2 - a nasel jsem libapache2-mod-chroot. Nejprve jsem nechapal jak muze chroot byt jenom modul do apache, ale dokumentace poradila - apache normalne nastartuje, otevre vsechny soubory (vcetne knihoven) a porty, a teprve potom (uvnitr mod_chroot) zavola chroot() a jedeme. Takze misto aby se apache spoustel rovnou v chrootu, apache se o to postara sam. Vyhoda je, ze neni potreba do chrootu kopirovat vsechny knihovny ktery apache potrebuje. Bohuzel se to netyka cgi skriptu apod.
Puvodne jsem se chrootu bal, chtel jsem ho poradne prozkouset na virtualni masine, ale nakonec neni proc, rozchozeno behem par minut (kdyz nepocitam znovuzprovozneni nagiosu, kterymu najednou chybelo par souboru). Vrele vsem doporucuju. Snad je to stejne bezpecny jako zavolat chroot() a pak teprve spustit apache
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz