Jöhetne a Debianban az egybeolvasztott /usr

Debian

A Debian arra készül, hogy átalakítsa az alapértelmezett fájlrendszer struktúráját, ami így a Fedorához és CentOS-hez fog hasonlítani. A váltásra készülődés már az év eleje óta folyik, és mostanában került be az unstable (sid) ágba az a változás, hogy a debootstrap már tud egybeolvasztott /usr-t használva is telepíteni. Ebben az esetben a /bin, /sbin, /lib szimbolikus linkek a /usr alatti hasonló nevű könyvtárakra.

A váltás egyik oka, hogy a Debian csomag karbantartókra jelentős terhet ró a jelenlegi rendszer. Egy másik ok, hogy jelenleg a /usr ugyan mountolható csak olvasható módon, de írható / esetén a /bin, /sbin és /lib alatti fájlokat, például valami malware, adott esetben írni tudja. Ha minden rendszerprogram a /usr alatt lesz csak olvashatóan mountolva, ez a biztonságot is növeli.

Ha valaki külön fájlrendszernek kívánja használni a / és /usr-t, csupán annyit kell tennie, hogy az initramfs-nek a root mellett a /usr-t is fel kell mountolnia.

További részletek itt.

( uzsolt v | 2016. 11. 27., v – 14:49 )

A váltás egyik oka, hogy a Debian csomag karbantartókra jelentős terhet ró a jelenlegi rendszer.

Ez nagyon érdekelt, elolvastam a cikkben linkelt levelet.
Arra, hogy pl. egy /bin-be települt, boot-kor induló alkalmazás egy olyan alkalmazást (libet) igényel, amely a (csak később csatolandó) /usr-ben van, miért az a megoldás, hogy mindent egybe rakunk? Nem vagyok rendszermérnök, de ez nem tervezési hiba (vagy egy jó terv rossz megvalósulása)?

Ha a /bin alatt csak szimbolikus linkek vannak

Ezt hol írják? Lehet, hogy így van, nem használok Debian-t.

Konkrétan a levél ezen részére gondoltam:

There have been various
unexpected dependencies on /usr in at least some packages for at least
that long (such as sysvinit scripts that use binaries in /usr without
depending on $remote_fs).

( mauzi v | 2016. 11. 27., v – 20:00 )

... és akkor itt jön a kérdés, hogy a Devuan is átveszi-e, vagy éppenséggel forkoljuk a Devuan-t is, ha normális könyvtárazást akarunk :)

- Simpler and cleaner overall file system layout, with full compatibility.
- Clear separation of operating system and host specific resources.
- Improve compatibility with other Unixes/linux, no confusion about tools install locations, no $PATH fiddling, all possible paths to a binary will always work. All binaries will be available on both /usr and / thus minimizing compatibility problems.
- Improve compatibility with build systems such as GNU autotools who never have been aware of the /usr split in the first place
- Minimize difference to other Unixes, such as Solaris, which already did the same move
- Isolate the vendor-supplied mostly read-only operating system resources from the rest, thus allow snapshotting of the OS, and easy lightweight container OS duplication

https://fedoraproject.org/wiki/Features/UsrMove

( NevemTeve | 2016. 11. 27., v – 20:49 )

Fiatalok kedvéért: régen az volt a koncepció, hogy mondjuk a /usr-en kívül van 10MB szoftver, azon belül meg 10GB; de ami /usr-ben van, az egy esetleges hiba utáni rendszer-helyreállításnál nem esszenciális, tehát adott esetben fel sem kell mountolni.

Pl az IBM-nek se sikerült elfogadnia ezt a koncepciót, az AIX-ban is csak szimlink-ként létezik a /bin, /sbin, /lib a /usr -beli megfelelőjükre.

Szerk: mondjuk régen sok furcsa dolog volt, például egy tipikus szerveren nem hogy Gnome3 / Kde5 nem volt, de még X-szerver sem. (Minek is lett volna, tipikusan képernyő és billentyűzet se volt.)

régen az volt a koncepció, hogy mondjuk a /usr-en kívül van 10MB szoftver, azon belül meg 10GB

FreeBSD-nél még most is ez a koncepció, persze kicsit más a rendszer felépítése is a Linux-hoz képest (gondolok arra, hogy pl. a cp, mount, stb. parancsok a csomagkezelő "hatáskörén" kívül vannak (azaz nem a coreutils és hasonló csomagok tartalmazzák), ők az alaprendszer részei, a freebsd-update paranccsal frissítheted).

( hnsz2002 v | 2016. 11. 27., v – 20:39 )

Nem értem, ez a biztonságot miért növeli..

rm /bin
mkdir /bin
cd /bin
ln -s /usr/bin/* .
mv mymalware /bin/bash
--
"Sose a gép a hülye."

( uid_228 | 2016. 11. 28., h – 13:29 )

Már megint a hurrikán a szarosbiliben...

A Solaris ezt rég meglépte, már a 10-esben a root device-on csak /sbin volt és speciális binárisok /etc alatt, ami mind csak ahhoz kellett, hogy nagyobb probléma eseten, single user módban lehessen kezdeni a rendszerrel valamit, javítani (még nagyobb gáznál meg úgyis resuce ISO-t bootol az ember). Egy normál bootfolyamat az /usr-t elég korán fölcsatolja, minden más program mehetett oda (no meg persze /opt alá és egyéb helyekre).

De ennek Solarison is csak a ZFS előtti időkben volt igazán értelme (és ez igaz FreeBSD-re is, illetve btrfs-re Linuxban), amíg a / és az /usr külön block device-on volt. A ZFS a root poolt dinamikusan osztja föl, / és /usr is egy poolon vannak, nem sok értelme van köztük különbséget tenni.

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

csak a ZFS előtti időkben volt igazán értelme

Mit szólsz egy olyan esethez, hogy egy egyszerű kliens, amelyen az alaprendszer van, és a /usr-t hálózati meghajtón van. Nem tudom, manapság még mennyire van ilyen, de ez is egy fő ok volt a kettéválasztáshoz (persze helyi hálózaton belül el tudok képzelni egy ilyet manapság is, hogy egy szerver, és sok vékonykliens csatlakozik hozzá - a szoftveres karbantartás, pl. programok frissítése lényegesen egyszerűbb; persze ha a szerver fertőződik valamivel, akkor az mindre kihat ;) ).
Persze egy szimpla egyszeri gépen annyira túl sok jelentősége valóban nincs (persze nálam külön partíción vannak - az okát ne kérdezd, lehet, hogy csak a geek-faktor vagy az e-penis növelése lehet a cél).

Ezt úgy értettem, hogy ZFS-nél már nincs értelme, de még mindig meg lehet csinálni. Mondjuk most hirtelen meg nem mondom neked fejből, hogy az ilyen jellegű setup még támogatott-e hivatalosan Solaris 11 alatt. :)

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Hát ööö, izé, lehet, hogy azok az épeszűek akik Solarist használtak azok nem csináltak külön /usr -t (speciel a HP-UX is meglépte ugyanezt a/bin -> /usr/bin marhaságot), de attól még az önálló /usr egy kicsit könnyebb kézbentarthatóságot nyújtott. (Kézben, nem pedig karban.) Gondolok itt a szokásos non-exec root vs exec,ro /usr helyzetre mondjuk. Az nem érv, hogy a linuxos ld.so huncutsága miatt ezt mennyire könnyű vagy nem könnyű átlépni. És valóban, a ZFS, btrfs (vagy akár a Tru64-es AdvFS alatt) már fizikailag sem különültek el ennyire a "partíciók", ezzel együtt is szerver használatnál - nekem - szimpatikusabb az önálló /usr. Biztos azok a fránya megszokások.

Azt azért megkérdem, hogy vannak-e olyanok, akiknek nem RAM-diszken van a /tmp, és lelkesen helyeselnek-e a miatt, hogy akkor a /-ben levő (azaz nem önálló) /tmp -t kezdjünk el használni. Van pár szerver, ahol a használat miatt nem megoldás a memóriában levő tmpfs, de akkor a fenti gondolatmenet alapján az nem is baj, hogy a /tmp ott van a /-ben - rosszabb esetben nincs sehol, hanem csak /tmp -> /usr/tmp. (Sok sikert a single bootban való gatyába rázáshoz, mert ilyenkor - mármint symlinkes esetben - ugye nincs semmilyen temporary területed.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

A följebb említett unixos security könyv már akkor azt írta, hogy a /tmp-t illik külön filerendszerre tenni, pont azért, hogy vmi elszabadult program ne tojja tele a root FS-t. Solarison meg ugye mindig a memóriában/swapen van by default, lehet is ezzel huncutkodni. :)

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Nem lényeges a memória, hiszen a tmpfs nem a RAM-ban lakik, hanem a virtuális memóriában. Ha betelik a RAM, majd kirakja a swapre. Ez tulajdonképpen ideális is, mert az amúgy üresen álló swapet lehet erre használni, nem kell külön diszket adni neki. Plusz nem kell bootnál takarítani a régi szemetet.

A nonexec rootnak kb. semmi értelmét nem látom (a root user szopatásán felül)... a full ro /usr meg mire jó? Aki tudna bele írni, az tud nyomni rá egy remountot is. Ennél sokkal értelmesebb megoldás ugyanerre a feladatra a chroot + ro + grsec, na ott a chrootolt processz uid=0 esetén sem tud remountot nyomni.

Van pár szerver, ahol a használat miatt nem megoldás a memóriában levő tmpfs

Nehéz elképzelni, hogy miféle használat is lehet ez...
De ha valakinek dedikált diszkterület kell alája mindenképp, akkor ne sajnáljon neki külön fs-t gyártani erre a célra.

A grsec biztosan sokkal jobb megoldás, csak kb egyetlen elterjedt disztróban sincs gyárilag grsec, míg mount igen. Ha jól tudom, még mindig ott tartunk, hogy SELinux van vagy AppArmnor. Ha valakinek már van joga remountot mondani, akkor kb tök mindegy. A grsec - véleményem szerint - azért jó, mert ehhez az extra joghoz nehezebb grsecet használó rendszer esetén hozzájutni.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nekem kellett már azért újratelepítenem SCO Unixot, mert az egyik kolléga ügyetlenül adott ki valami parancsot rootként.
Az otthoni Debianomon is ro a /usr, és főleg azért, hogy véletlenek ne írják felül. Ha frissíteni akarok, majd remountolom rw. Utána ro újra.
Mellesleg áramszünet vagy ilyesmi után se dirty vagy sérült a fájlrendszer.

Erre nem emlékeztem, pedig 2.5.1-nél terelgettem először Solarist. :)

A leválasztott /usr-nek azért van értelme, pl. security szempontból. Emlékszem, hogy egy 1996-97-es Practical Unix Security még megemlítette, hogy az /usr-t rakhatod külön SCSI drive-ra, amit hardveresen írásvédetté tehetsz (külső drive-on kapcsoló) és onnét kezdve a gépre bejutú malicsusz ember/kód nem tudja azokat a binárisokat módosítani. :)

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”