Utgivelse av systemet med selvforsynt pakker Flatpak 1.14.0

En ny stabil gren av Flatpak 1.14-verktøysettet har blitt publisert, som gir et system for å bygge selvstendige pakker som ikke er knyttet til spesifikke Linux-distribusjoner og kjøres i en spesiell beholder som isolerer applikasjonen fra resten av systemet. Støtte for å kjøre Flatpak-pakker er gitt for Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux og Ubuntu. Flatpak-pakker er inkludert i Fedora-depotet og støttes av den opprinnelige GNOME-applikasjonsbehandleren.

Nøkkelinnovasjoner i Flatpak 1.14-grenen:

  • Det er mulig å lage en katalog for filer i tilstand (.local/state) og sette XDG_STATE_HOME miljøvariabelen som peker til denne katalogen.
  • Lagt til betingede kontroller av formen "have-kernel-module-name" for å bestemme tilstedeværelsen av kjernemoduler (en universell analog til den tidligere foreslåtte have-intel-gpu-kontrollen, i stedet for uttrykket "have-kernel-module-i915 " kan nå brukes).
  • Kommandoen "flatpak document-unexport —doc-id=..." er implementert.
  • Eksport av Appstream-metadata for bruk i hovedmiljøet leveres.
  • La til flatpak-kommandofullføringsregler for fiskeskallet
  • Nettverkstilgang til X11- og PulseAudio-tjenester er tillatt (hvis de riktige innstillingene er lagt til).
  • Hovedgrenen i Git-depotet har blitt omdøpt fra "master" til "main", siden ordet "master" nylig har blitt ansett som politisk ukorrekt.
  • Lanseringsskript skrives nå om hvis programmet får nytt navn.
  • Lagt til alternativene "--include-sdk" og "--include-debug" til installeringskommandoen for å installere SDK- og debuginfo-filene.
  • Lagt til støtte for "DeploySideloadCollectionID"-parameteren til flatpakref- og flatpakrepo-filene. Når den er angitt, vil samlings-IDen bli satt når du legger til et eksternt depot, og ikke etter å ha lastet metadataene.
  • Tillot opprettelse av nestede sandkassemiljøer for behandlere i økter med separate MPRIS-navn (Media Player Remote Interfacing Specification).
  • Kommandolinjeverktøy gir nå informasjon om bruken av utdaterte kjøretidsutvidelser.
  • Avinstalleringskommandoen implementerer en bekreftelsesforespørsel før du fjerner kjøretids- eller kjøretidsutvidelser som fortsatt er i bruk.
  • Lagt til støtte for "--socket=gpg-agent"-alternativet til kommandoer som "flatpak run".
  • En sårbarhet er rettet i libotree som potensielt kan tillate en bruker å slette vilkårlige filer på systemet gjennom manipulering av flatpak-system-helper-behandleren (sende en sletteforespørsel med et spesielt formatert filialnavn). Problemet vises kun i eldre versjoner av Flatpak og libotree utgitt før 2018 (< 0.10.2) og påvirker ikke nåværende utgivelser.

La oss minne deg på at Flatpak lar applikasjonsutviklere forenkle distribusjonen av programmene deres som ikke er inkludert i standard distribusjonslagre ved å klargjøre en universalbeholder uten å lage separate sammenstillinger for hver distribusjon. For sikkerhetsbevisste brukere lar Flatpak deg kjøre en tvilsom applikasjon i en container, og gir kun tilgang til nettverksfunksjonene og brukerfilene knyttet til applikasjonen. For brukere som er interessert i nye produkter, lar Flatpak deg installere de siste test- og stabile utgivelsene av applikasjoner uten å måtte gjøre endringer i systemet. For eksempel er Flatpak-pakker bygget for LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 AD, Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, etc.

For å redusere pakkestørrelsen inkluderer den bare applikasjonsspesifikke avhengigheter, og de grunnleggende system- og grafikkbibliotekene (GTK, Qt, GNOME og KDE biblioteker, etc.) er utformet som plug-in standard kjøretidsmiljøer. Den viktigste forskjellen mellom Flatpak og Snap er at Snap bruker komponentene i hovedsystemmiljøet og isolasjon basert på filtrering av systemanrop, mens Flatpak oppretter en container separat fra systemet og opererer med store kjøretidssett, og gir ikke pakker som avhengigheter, men standard. sine systemmiljøer (for eksempel alle biblioteker som er nødvendige for driften av GNOME- eller KDE-programmer).

I tillegg til standard systemmiljø (runtime), installert gjennom et spesielt depot, leveres ytterligere avhengigheter (bunt) som kreves for driften av applikasjonen. Totalt sett utgjør runtime og bunt fyllingen av containeren, til tross for at runtime er installert separat og knyttet til flere containere samtidig, noe som lar deg unngå duplisering av systemfiler som er felles for containere. Ett system kan ha flere forskjellige kjøretider installert (GNOME, KDE) eller flere versjoner av samme kjøretid (GNOME 3.40, GNOME 3.42). En container med en applikasjon som avhengighet bruker en binding kun til en spesifikk kjøretid, uten å ta hensyn til de individuelle pakkene som utgjør kjøretiden. Alle manglende elementer pakkes direkte med applikasjonen. Når en beholder dannes, monteres kjøretidsinnholdet som /usr-partisjonen, og bunten monteres i /app-katalogen.

Runtime- og applikasjonsbeholderne er bygget ved hjelp av OSTree-teknologi, der bildet er atomisk oppdatert fra et Git-lignende depot, som lar versjonskontrollmetoder brukes på distribusjonskomponentene (du kan for eksempel raskt rulle tilbake systemet til en tidligere tilstand). RPM-pakker oversettes til OSTree-depotet ved hjelp av et spesielt rpm-otree-lag. Separat installasjon og oppdatering av pakker i arbeidsmiljøet støttes ikke; systemet oppdateres ikke på nivå med individuelle komponenter, men som en helhet, og endrer atomisk tilstand. Gir verktøy for å bruke oppdateringer trinnvis, og eliminerer behovet for å erstatte bildet fullstendig med hver oppdatering.

Det genererte isolerte miljøet er helt uavhengig av distribusjonen som brukes, og med riktige innstillinger av pakken, har ikke tilgang til filer og prosesser til brukeren eller hovedsystemet, kan ikke få direkte tilgang til utstyret, med unntak av utdata via DRI, og anrop til nettverksdelsystemet. Grafikkutgang og inndataorganisering implementeres ved hjelp av Wayland-protokollen eller via X11-socket-videresending. Interaksjon med det eksterne miljøet er basert på DBus meldingssystem og en spesiell Portals API.

For isolasjon brukes Bubblewrap-laget og tradisjonelle Linux-beholdervirtualiseringsteknologier, basert på bruk av cgroups, namespaces, Seccomp og SELinux. PulseAudio brukes til å sende ut lyd. I dette tilfellet kan isolasjon deaktiveres, som brukes av utviklerne av mange populære pakker for å få full tilgang til filsystemet og alle enhetene i systemet. For eksempel kommer GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity og VLC med en begrenset isolasjonsmodus som gir full tilgang til hjemmekatalogen. Hvis pakker med tilgang til hjemmekatalogen blir kompromittert, til tross for tilstedeværelsen av "sandboxed"-etiketten i pakkebeskrivelsen, trenger angriperen bare å endre ~/.bashrc-filen for å utføre koden sin. Et eget problem er kontroll av endringer i pakker og tillit til pakkebyggere, som ofte ikke er knyttet til hovedprosjektet eller distribusjonene.

Kilde: opennet.ru

Legg til en kommentar