Proxmox lxc konténer bind mount jogosultság probléma

Linux-kezdő

Sziasztok!

Egy kicsit elakadtam proxmox/lxc témában.

Felvázolnám, hogy eddig mit csináltam:
proxmoxon létrehoztam egy mappát (/srv/www/), ezt bind mountoltam egy lxc konténerbe.
Proxmoxon ha a www könyvtárnak a lokális www-data:www-data tulajdonost adom meg és megcsinálom a lxc.idmap-ot az alábbi módon, akkor működik (a konténerben is www-data:www-data lesz a tulajdonos, ahogyan kell):

lxc.idmap: u 0 100000 33
lxc.idmap: g 0 100000 33
lxc.idmap: u 33 33 1
lxc.idmap: g 33 33 1
lxc.idmap: u 34 100034 65502
lxc.idmap: g 34 100034 65502

(/etc/subgid és /etc/subuid-ban beállítva a root:33:1, ahogyan kell)

Ha viszont lokálisan egy nem létező csoportra akarom map-elni (lxc.idmap: x 33 2000 1) és chown 2000:2000 az /srv/www -re (subgid és subuid root:2000:1-re módosítva), akkor viszont Permission denied-ot kapok.

Esetleg valaki útba igazítana, hogy mi a helyes eljárás ilyen esetben és mi az amit kihagyok?
(Természetesen a 2000-es id bármilyen tetszőlegesen magas id-ra módosítható, nincs kőbe vésve, a lényeg annyi lenne, hogy a konténer 33-as id lokálisan ne a 33-as uid:gid párossal fusson, hanem valami magasabbal)

  • 348 megtekintés

( procika v | 2021. 11. 07., v – 10:00 )

Szia! Tanulási szándékkal kérdeznék. Ez így miért jó? Mármint a fizikai gép lemezés mountolni direktben?

( fefy | 2021. 11. 07., v – 19:01 )

Szia, teljes egészében tanulási szándék. Élesben nem így csinálnám, de tanulási céllal jó lenne ezt is megoldani. Igazából érdekelne a megoldás menete, mert ki tudja, hogy mikor jön jól ez a fajta tudás.

A lényeg lényege lényegében lényegtelen.

A kérdésedre nem tudok választ adni, csak egy ok amiért nem csinálnék ilyet. Ez mondjuk akkor lehet jó meglátásom szerint, ha mondjuk van egy szervered amiben van 2 db RAID tömb. Egyiken a Proxmox és a VM-ek, a másik szabadon felhasználható. Van valami VM-ed aminek nem kell nagy processzor és RAM, de sok tárhely kell. Ha futás közben akarod menteni a VM-et, akár helyi lemezre akár PBS-re, az egész fizikai lemezt magával fogja húzni. De szerintem a ha kikapcsolva mented akkor is. Én nemrég kipróbáltam egy olyat, hogy a Proxmox alá egy VM-be tettem a Proxmox Backup Servert. ICSI egy Synologyról betettem egy meghajtót a VM-nek, plusz lemeznek, hogy arra mentse majd a gépeket ami az ő hostján futnak. Ezzel hatamas marhaságot csináltam mert elkezdte kiexportálni a NAS tartalmát is. Végül inkább NFS-en át mountolom FSTAB-al a Syno megosztást és azt látja a PSB. Így ha kikapcsolom a PSB VM-et le tudom menteni, az NFS megosztást így nem fogja húzni.

Proxmox-ban diszkenként tudod konfigurálni, hogy a mentésbe bekerüljön vagy sem az adott diszk.

Bind mount akkor kell(het), mikor nem-privilegizált konténerbe szeretnél távoli tárhelyet felcsatolni. Ugyanis a nem-privilegizált kontérenben pl. nem tudsz NFS-t felcsatolni. Ilyenkor a host-ra csatolod fel és mehet a bind mount a konténerbe. Ez még mindig jobb biztonság terén, mint privilegizált konténert futtatni. De ha valami egyéb okból privilegizált a konténer mindenképp, akkor felesleges kör és macera a bind mount a belső mount helyett.

Szia,

Mivel ez nekem mindig is szürke folt volt, így ezért kezdtem el ezzel is foglalkozni (legyen valami stabil alap, utána jöhet a docker/kubernetes). Ha jól értem, amit írtál, akkor amit kitaláltam, az nem is annyira az ördögtől való és nem privilegizált konténerben kb valami hasonló az arany középút.

Egyébként amit még próbáltam: Nem privilegizált konténerben bekapcsoltam a FUSE opciót és így manuálisan ment az SSHFS mountolás. Ez igaz, hogy némileg lassabb, mint az NFS, viszont ha nagyon világvége van, akkor ez jól jöhet. A hátránya viszont, hogy nem sikerült automatikusra megcsinálnom, mivel ehhez kellene az automount, ami már kéri a privilegizált konténert a nested-el együtt, szóval ez is egy kicsit zsákutca ilyen téren.

Esetleg van valami megoldásod az eredeti felvetésemre, vagy ezt így ebben a formában inkább engedjem el?

A lényeg lényege lényegében lényegtelen.

Az eredeti kérdésre a tuti választ nem tudom. De azt gondolom, hogy ha bármelyik oldalon nem létező UID van, akkor az az oldali rendszer nem tudja hitelesíteni a kérést, szóval meg fog bukni a hozzáférés. A jogosultság ellenőrzése nem úgy működik, hogy az általad megadott idmap-es uid-et simán összehasonlítja a mappán lévővel, és kész, ha egyezik olvashatod. Így nagyon könnyen átverhető lenne minden rendszer. A kérdező átadja a cél rendszernek, hogy "ez az uid hozzá szeretne férni ehhez a mappához", aztán az adott rendszer gyorsan válaszol is, hogy ez ismeretlen uid számára, így hozzáférés megtagadva. De ezt csak gondolom (nekem így logikus), sosem próbáltam nem lézető user-nek adott tartalomhoz hozzáférni...

Ha el akarod kerülni, hogy egy általánosan használt uid legyen az adott könyvtár tulajdonosa, akkor szerintem csinálj egy új user-t a host-on tetszőleges uid-del aminek csak arra az adott könyvtárra van joga, és arra írd az idmap-et a nem-privilegizált konténerhez. Ha privilegizált a konténer, akkor ugye egyeznek az uid-ek a konténer és a host között.

Meg a bind mount, és egyéb, host-hoz kötődő szolgáltatások igénybe vételénél vegyétek figyelembe, hogy ezekkel kezditek megölni (részben) a virtualizációt (az adott hardvertől függetlenítést), mert ilyen felállással mozgathatatlanná válik az egész konténer, így csak azon az egy host-on lesz életképes.

Félre ne érts, nem akarom hozzádrótozni a host rendszerhez a konténert, de egyelőre ez tűnik a legkevésbé rossz megoldásnak (függetlenül attól, hogy nem éles rendszer, hanem csak játszadozni raktam össze).

Az egész dolog az alábbi miatt fogalmazódott meg bennem: privilegizált konténert nem szeretnék futtatni, pont azért mert kitörés esetén root jogokkal lehet a hoston kalózkodni (teszt rendszer lévén ez nem valós probléma, de inkább jól tanuljam meg, mint kényelmesen). Ezt elkerülendő, próbáltam nfs-t/sshfs-t automatikusan felcsatolni a konténerben. Mindkét esetben szükség van a privilegizált konténerre. Mivel ugyanott vagyok, hogy privilegizált, vagy manuális csatolás (sshfs esetén ez működik), így elkezdtem a bind mount irányába nézelődni. Ennél is jó lenne elkerülni, hogy a konténer 33-as id-ja a host 33-as id-ját használja. Ezzel viszont kinyírom a hordozhatóságot, szóval a szerény tudásommal én körbe is értem.

B tervként szóba jöhet a fullos virtuális gép, de egy mezei webszervernek (óránként pár 10 kéréssel) egy teljes gépet felhúzni kissé ágyúval verébre sztorinak tűnik nekem.

A lényeg lényege lényegében lényegtelen.

Én itthon futtatok még pár konténert, de mivel a legtöbb feladat, amit meg kell oldanom igényel tárterületet vagy egyéb szolgáltatást ami csak privilegizált konténerben működik rendesen, így mostanra egyáltalán nem használok máshol konténereket. Nem olyan feladatokba futok, amiket ilyen konténerekkel lehet optimálisan megoldani.

Inkább teljes VM (template-ből, hogy gyorsan meglegyen). A mai hardvereken már igazából észrevehetetlen az az overhead, ami ezzel jár (legalábbis az én rendszereimnél).

Ha pedig konténerezni szeretnék valamit mégis, akkor inkább Docker alapon teszem.

Játszottam egy kicsit a dologgal és amit tapasztaltam:

Ha sshfs-el felcsatolok a hostra egy megosztást, ezt bind mountolom, akkor elég a konténerben felvenni a kérdéses uid-vel usert, a hoston nem kell léteznie, elég ha a megosztó szerveren létezik a kérdéses uid.

Ha a host lokális mappáját (pl másik raid kötet a hoston) bind mountolom, akkor itt viszont már léteznie kell a kérdéses uid-s usernek.

Tehát az eredeti kérdésemre: ha felveszek egy ct-www-data usert 2000-es id-vel a hoston, akkor ezt tudom a konténerben levő 33-as id-val rendelkező www-data-ra irányítani.

Az, hogy ez szép vagy jó megoldás, nem mondanám, de működik, szóval köszi a tippet.

Egyébként ha mindezt átültetem majd élesbe, akkor kérdéses a dolog, de ha proxmox marad a host rendszer, akkor security oldalról szinte mindegy, hogy vm, vagy konténer, mert mindkettő root joggal fut, csak utóbbinak kisebb az overhead-je, na meg az egész úgyis el lesz rejtve haproxy-val egy pfsense mögött.

A lényeg lényege lényegében lényegtelen.

Szia!

Azt nem tudtam lehet állítani melyik kerüljön bele, megnézem. Az NFS-re már rájöttem. :) Mostanság kezdek átállni konténerre, kezdem unni az eltűnő virtuális lemez partíciókat KVM alatt. Most már a mentések is hibásak voltak, onnan visszatöltve sem indult el a VM.

Az "eltűnő lemezek" valami hiba amit érdemes lenne megkeresni. Nekem még sohasem fordult elő ilyen. Tippre valami hiba lehet a host gép diszk alrendszerében vagy fájlrendszerében. Ha így van, akkor konténerekkel ugyan így elő fog jönni.

Konténerben olyasmit érdemes futtatni, ami eldobható és újra előállítható könnyen. Kb. pont azok az elvek mint Docker vagy Kubernetes terén: a konténer legyen stateless (tehát ne legyen saját tárterülete semmilyen formában, csak végrehajtást csináljon). Amikor már saját tárterület kell egy szolgáltatásnak (pl. adatbázis szerver), akkor oda a VM a jobb választás. A konténerekkel (is) mindent meg lehet csinálni, de sok célre nem praktikusak/nem igazán valók.

Több gépen is előfordult. Mind Dell. Én inkább a VirtIO SCSI vagy LSI beállításban láttam szabályszerűséget. Minden adat megmarad a virtuális lemezen, csak a partíciós tábla tűnik el. Testdisk mindent lát rajta. Én levelező szervereket tettem konténerbe. Kevés RAM és proci kell neki, a tárterületet tudom növelni ha kell minden macera nélkül. Helyreállítani sem bonyolult fájl szintű mentésből sem. Minden éjjel van amúgy Proxmox Backup Serverre mentés. 3 szóló szerverem van, nincs közös tárolóm.