'n Monteer-naamruimte is 'n Linux-kernelkenmerk wat isolasie van die lêerstelsel-monteerpunte wat deur 'n groep prosesse gesien word, bied. Elke monteer-naamruimte het sy eie stel lêerstelsel-monteerpunte, en veranderings aan die monteerpunte in een naamruimte beïnvloed nie ander naamruimtes nie. Dit beteken dat prosesse wat in verskillende monteer-naamruimtes loop, verskillende sienings van die lêerstelsel-hierargie kan hê.
Monteer-naamruimtes is veral nuttig in konteinerisering, waar elke konteiner sy eie lêerstelsel en konfigurasie moet hê, geïsoleer van ander konteinere en die gasheerstelsel.
Hoe dit werk:
Wanneer 'n nuwe monteer-naamruimte geskep word, word dit geïnisialiseer met 'n kopie van die monteerpunte van sy ouer-naamruimte. Dit beteken dat, by skepping, die nuwe naamruimte dieselfde siening van die lêerstelsel deel as sy ouer. Tog sal enige volgende veranderinge aan die monteerpunte binne die naamruimte nie die ouer of ander naamruimtes beïnvloed nie.
Wanneer 'n proses 'n monteerpunt binne sy naamruimte wysig, soos die monteer of ontmonteer van 'n lêerstelsel, is die verandering plaaslik in daardie naamruimte en beïnvloed dit nie ander naamruimtes nie. Dit maak dit moontlik dat elke naamruimte sy eie onafhanklike lêerstelsel-hierargie het.
Prosesse kan tussen naamruimtes beweeg deur die setns()-sisteemaanroep te gebruik, of nuwe naamruimtes skep deur die unshare()- of clone()-sisteemaanroep met die CLONE_NEWNS-vlag te gebruik. Wanneer 'n proses na 'n nuwe naamruimte beweeg of een skep, sal dit begin om die monteerpunte wat met daardie naamruimte geassosieer word, te gebruik.
Lêerbeskrywers en inodes word oor naamruimtes gedeel, wat beteken dat as 'n proses in een naamruimte 'n oop lêerbeskrywer het wat na 'n lêer wys, kan dit daardie lêerbeskrywer aan 'n proses in 'n ander naamruimte oordra, en beide prosesse sal toegang tot dieselfde lêer hê. Die lêer se pad mag egter nie dieselfde wees in beide naamruimtes as gevolg van verskille in monteerpunte nie.
Laboratorium:
Skep verskillende Naamruimtes
CLI
sudounshare-m [--mount-proc] /bin/bash
Deur 'n nuwe instansie van die /proc-lêersisteem te monteer as jy die parameter --mount-proc gebruik, verseker jy dat die nuwe berg-namespace 'n akkurate en geïsoleerde siening van die prosesinligting spesifiek vir daardie namespace het.
Fout: bash: fork: Kan nie geheue toewys nie
Wanneer unshare uitgevoer word sonder die -f-opsie, word 'n fout aangetref as gevolg van die manier waarop Linux nuwe PID (Proses-ID)-namespaces hanteer. Die sleuteldetails en die oplossing word hieronder uiteengesit:
Probleemverduideliking:
Die Linux-kernel maak dit moontlik vir 'n proses om nuwe namespaces te skep deur die unshare-sisteemaanroep te gebruik. Die proses wat die skepping van 'n nuwe PID-namespace inisieer (bekend as die "unshare"-proses) betree egter nie die nuwe namespace nie; slegs sy kinderprosesse doen dit.
Die uitvoering van %unshare -p /bin/bash% begin /bin/bash in dieselfde proses as unshare. Gevolglik is /bin/bash en sy kinderprosesse in die oorspronklike PID-namespace.
Die eerste kinderproses van /bin/bash in die nuwe namespace word PID 1. Wanneer hierdie proses afsluit, veroorsaak dit die skoonmaak van die namespace as daar geen ander prosesse is nie, aangesien PID 1 die spesiale rol het om weesouerprosesse aan te neem. Die Linux-kernel sal dan PID-toekenning in daardie namespace deaktiveer.
Gevolg:
Die afsluiting van PID 1 in 'n nuwe namespace lei tot die skoonmaak van die PIDNS_HASH_ADDING-vlag. Dit veroorsaak dat die alloc_pid-funksie misluk om 'n nuwe PID toe te ken wanneer 'n nuwe proses geskep word, wat die "Kan nie geheue toewys nie" -fout veroorsaak.
Oplossing:
Die probleem kan opgelos word deur die -f-opsie saam met unshare te gebruik. Hierdie opsie maak unshare 'n nuwe proses na die skepping van die nuwe PID-namespace.
Deur %unshare -fp /bin/bash% uit te voer, verseker jy dat die unshare-opdrag self PID 1 in die nuwe namespace word. /bin/bash en sy kinderprosesse word dan veilig binne hierdie nuwe namespace gehou, wat die voortydige afsluiting van PID 1 voorkom en normale PID-toekenning moontlik maak.
Deur te verseker dat unshare met die -f-vlag uitgevoer word, word die nuwe PID-namespace korrek onderhou, sodat /bin/bash en sy subprosesse kan werk sonder om die geheue-toewysingsfout te ondervind.
Om te bepaal in watter namespace jou proses tans is, kan jy die volgende opdrag gebruik:
cat/proc/$$/mountinfo|grep"ns"
Hierdie opdrag sal die mountinfo-lêer van jou huidige proses ($$) lees en die reëls filter wat die woord "ns" bevat. Die uitset sal die namespace-identifiseerders vir jou proses toon.
sudofind/proc-maxdepth3-typel-namemnt-execreadlink{} \; 2>/dev/null|sort-u# Find the processes with an specific namespacesudofind/proc-maxdepth3-typel-namemnt-execls-l{} \; 2>/dev/null|grep<ns-number>
```bash nsenter -m TARGET_PID --pid /bin/bash ``` Verder kan jy slegs **toegang verkry tot 'n ander proses-namespace as jy root is**. En jy kan **nie** **toegang verkry** tot 'n ander namespace **sonder 'n beskrywer** wat daarna verwys nie (soos `/proc/self/ns/mnt`).
Omdat nuwe bergings slegs binne die namespace toeganklik is, is dit moontlik dat 'n namespace sensitiewe inligting bevat wat slegs daarvandaan toeganklik is.
Monteer iets
# Generate new mount nsunshare-m/bin/bashmkdir/tmp/mount_ns_examplemount-ttmpfstmpfs/tmp/mount_ns_examplemount|greptmpfs# "tmpfs on /tmp/mount_ns_example"echotest>/tmp/mount_ns_example/testls/tmp/mount_ns_example/test# Exists# From the hostmount|greptmpfs# Cannot see "tmpfs on /tmp/mount_ns_example"ls/tmp/mount_ns_example/test# Doesn't exist
