.\" -*- coding: UTF-8 -*- .\" Copyright (c) 2013 by Michael Kerrisk .\" and Copyright (c) 2012 by Eric W. Biederman .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH pid_namespaces 7 "30 mars 2023" "Linux man\-pages 6.05.01" .SH NAMN pid_namespaces — översikt över Linux PID\-namnrymder .SH BESKRIVNING För en översikt över namnrymder, se \fBnamespaces\fP(7). .PP PID\-namnrymder isolerar process\-ID\-nummerrymden, vilket betyder att processer i olika PID\-namnrymder kan ha samma PID. PID\-namnrymder gör att behållare kan åstadkomma funktionalitet såsom att stoppa/återuppta uppsättningen av processer i behållaren och migrera behållaren till en ny värd medan processerna inuti behållaren behåller samma PID:ar. .PP PID:ar i en ny PID\-namnrymd börjar på 1, ungefär som ett fristående system, och anrop av \fBfork\fP(2), \fBvfork\fP(2) eller \fBclone\fP(2) kommer skapa processer med PID:ar som är unika inom namnrymden. .PP .\" .\" ============================================================ .\" Användning av PID\-namnrymder kräver en kärna som är konfigurerad med alternativet \fBCONFIG_PID_NS\fP. .SS "Namnrymdens init\-process" Den första processen som skapas i en ny namnrymd (d.v.s., processen som skapas med \fBclone\fP(2) med flaggan \fBCLONE_NEWPID\fP, eller det första barnet som skapas av en process efter ett anrop av \fBunshare\fP(2) med flaggan \fBCLONE_NEWPID\fP) har PID:en 1, och är ”init”\-processen för namnrymden (se \fBinit\fP(1)). Denna process blir förälder för barnprocesser som blir föräldralösa för att en process som bor i denna PID\-namnrymd avslutas (se nedan för ytterligare detaljer). .PP Om ”init”\-processen i en PID\-namnrymd avslutas avslutar kärnan alla processerna i namnrymden med en signal \fBSIGKILL\fP. Detta beteende avspeglar faktumet att ”init”\-processen är avgörande för den korrekta funktionen hos en PID\-namnrymd. I detta fall kommer en senare \fBfork\fP(2) in i denna PID\-namnrymd att misslyckas med felet \fBENOMEM\fP; det är inte möjligt att skapa en ny process i en PID\-namnrymd vars ”init”\-process har avslutat. Sådana scenarier kan uppstå när, till exempel, en process använder en öppen filbeskrivare för en fil \fI/proc/\fPpid\fI/ns/pid\fP som motsvarar en process som fanns i en namnrymd för att göra \fBsetns\fP(2) in i den namnrymden efter att ”init”\-processen har avslutat. Ett annat möjligt scenario kan uppstå efter ett anrop av \fBunshare\fP(2): om det första barnet som därefter skapas av en \fBfork\fP(2) avslutar, då misslyckas senare anrop av \fBfork\fP(2) med \fBENOMEM\fP. .PP Endast signaler för vilka ”init”\-processen har etablerat en signalhanterare kan skickas till ”init”\-processen av andra medlemmar av PID\-namnrymden. Denna begränsning gäller även för privilegierade processer, och hindrar andra medlemmar av PID\-namnrymden från att av misstag döda ”init”\-processen. .PP På liknande sätt kan en process i en anfadernamnrymd \[em] med hänsyn till de vanliga rättighetskontrollerna som beskrivs i \fBkill\fP(2) \[em] skicka signaler till ”init”\-processen i en barn\-PID\-namnrymd endast om ”init”\-processen har etablerat en hanterare för den signalen. (Inom hanteraren kommer fältet \fIsiginfo_t\fP \fIsi_pid\fP som beskrivs i \fBsigaction\fP(2) att vara noll.) \fBSIGKILL\fP eller \fBSIGSTOP\fP hanteras speciellt: dessa signaler skickas tvingande när de skickas från en anfader\-PID\-namnrymd. Ingendera av dessa signaler kan fångas av ”init”\-processen, och kommer därför resultera i de vanliga åtgärderna som associeras med dessa signaler (avslut respektive stopp av processen). .PP .\" .\" ============================================================ .\" Med början från Linux 3.4 får systemanropet \fBreboot\fP(2) en signal att skickas till namnrymdens ”init”\-process. Se \fBreboot\fP(2) för mer detaljer. .SS "Nästning av PID\-namnrymder" .\" commit f2302505775fd13ba93f034206f1e2a587017929 .\" The kernel constant MAX_PID_NS_LEVEL PID\-namnrymder kan nästas: varje PID\-namnrymd har en förälder, utom den intitiala (”rot”) PID\-namnrymden. Förälder till en PID\-namnrymd är PID\-namnrymden för processen som skapade namnrymden med \fBclone\fP(2) eller \fBunshare\fP(2). PID\-namnrymder formar alltså ett träd, där alla namnrymder ytterst spårar sitt ursprung till rotnamnrymden. Sedan Linux 3.7 begränsar kärnan det maximala nästningsdjupet för PID\-namnrymder till 32. .PP En process är synlig för andra processer i sin PID\-namnrymd, och för processer i varje direkt anfaders\-PID\-namnrymd hela vägen tillbaka till rot\-PID\-namnrymden. I detta sammanhang betyder ”synlig” att en process kan vara målet för åtgärder av en annan process med systemanrop som anger ett process\-ID. Omvänt, processer i en barn\-PID\-namnrymd kan inte se processer i föräldranamnrymden och mer avlägsna anfadernamnrymder. Mer koncist: en process kan se (t.ex., skicka signaler till med \fBkill\fP(2), sätta nice\-värde på med \fBsetpriority\fP(2), etc.) endast processer som ingår i dess egen PID\-namnrymd och avkommor av den namnrymden. .PP En process har ett process\-ID i varje lager av PID\-namnrymdshierarkin i vilken den är synlig, och går tillbaka genom varje direkt anfadernamnrymd vidare till rot\-PID\-namnrymden. Systemanrop som verkar på process\-ID:er arbetar alltid med användning av process\-ID:t som är synligt i anroparens PID\-namnrymd. Ett anrop av \fBgetpid\fP(2) returnerar alltid PID:en som är associerad med namnrymden i vilken processen skapades. .PP Några processer i en PID\-namnrymd kan ha föräldrar som ligger utanför namnrymden. Till exempel, föräldern till den initiala processen i namnrymden (d.v.s., processen \fBinit\fP(1) med PID 1) finns av nödvändighet i en annan namnrymd. På samma sätt finns de direkta barnen till en process som använder \fBsetns\fP(2) för att få sina barn att gå med i en PID\-namnrymd i en annan PID\-namnrymd än den som anropade \fBsetns\fP(2). Anrop av \fBgetppid\fP(2) för sådana processer returnerar 0. .PP Medan processer fritt kan gå in i barn\-PID\-namnrymder (t.ex. med \fBsetns\fP(2) med en PID\-namnrymdsfilbeskrivare) kan de inte flytta i någon annan riktning. Det vill säga, processer kan inte gå in i någon anfadernamnrymd (förälder, farförälder, etc.). Att byta PID\-namnrymder är en envägsåtgärd. .PP .\" .\" ============================================================ .\" Åtgärden \fBNS_GET_PARENT\fP till \fBioctl\fP(2) kan användas för att upptäcka föräldrarelationen mellan PID\-namnrymder; se \fBioctl_ns\fP(2). .SS "semantiken hos setns(2) och unshare(2)" Anrop av \fBsetns\fP(2) som anger en PID\-namnrymdsfilbeskrivare och anrop av \fBunshare\fP(2) med flagga \fBCLONE_NEWPID\fP får barn som senare skapas av anroparen att placeras i en annan PID\-namnrymd än anroparens. (Från Linux 4.12 visas PID\-namnrymden via filen \fI/proc/\fPpid\fI/ns/pid_for_children\fP, så som beskrivs i \fBnamespaces\fP(7).) Dessa anrop ändrar dock inte PID\-namnrymden för den anropande processen, då detta skulle ändra anroparens uppfattning om sin egen PID (så som den rapporteras av \fBgetpid\fP()), vilket skulle göra sönder många program och bibliotek. .PP För att uttrycka saker på ett annat sätt: en process PID\-namnrymdsmedlemskap avgörs när processen skapas och kan inte ändras därefter. Bland annat betyder detta att föräldrarelationen mellan processer avspeglar föräldrarelationen mellan PID\-namnrymder: föräldern till en process finns antingen i samma namnrymd eller bor i den omedelbara föräldra\-PID\-namnrymden. .PP .\" .\" ============================================================ .\" En process kan anropa \fBunshare\fP(2) med flaggan \fBCLONE_NEWPID\fP endast en gång. Efter att den utfört denna åtgärd kommer dess symboliska länk \fI/proc/\fPpid\fI/ns/pid_for_children\fP att vara tom tills det första barnet är skapat i namnrymden. .SS "Adoption av föräldralösa barn" .\" Furthermore, by definition, the parent of the "init" process .\" of a PID namespace resides in the parent PID namespace. .\" .\" ============================================================ .\" När en barnprocess blir föräldralös flyttas den över till ”init”\-processen i PID\-namnrymden för dess förälder (om inte en av de närmare anfäderna till föräldern har använt kommandot \fBprctl\fP(2) \fBPR_SET_CHILD_SUBREAPER\fP för att markera sig själv som den som skördar avkommeprocesser som blir föräldralösa). Observera att på grund av semantiken hos \fBsetns\fP(2) och \fBunshare\fP(2) som beskrivs ovan kan detta vara ”init”\-processen i PID\-namnrymden som är \fIförälder\fP till barnets PID\-namnrymd, istället för ”init”\-processen i barnets egen PID\-namnrymd. .SS "Kompatibilitet hos CLONE_NEWPID med andra CLONE_*\-flaggor" I de nuvarande versionerna av Linux kan inte \fBCLONE_NEWPID\fP kombineras med \fBCLONE_THREAD\fP. Trådar måste befinna sig i samma PID\-namnrymd så att de kan skicka signaler till varandra. Vidare måste det vara möjligt att se alla trådarna hos en process i filsystemet \fBproc\fP(5). Dessutom, om två trådar skulle vara i olika PID\-namnrymder skulle inte process\-ID:t för processen som skickar en signal kunna kodas på ett meningsfullt sätt när en signal skickas (se beskrivningen av typen \fIsiginfo_t\fP i \fBsigaction\fP(2)). Eftersom detta beräknas när en signal köas upp skulle en signalkö delad mellan processer i flera PID\-namnrymder omöjliggöra det. .PP .\" Note these restrictions were all introduced in .\" 8382fcac1b813ad0a4e68a838fc7ae93fa39eda0 .\" when CLONE_NEWPID|CLONE_VM was disallowed .\" (restriction lifted in faf00da544045fdc1454f3b9e6d7f65c841de302) .\" (restriction lifted in e79f525e99b04390ca4d2366309545a836c03bf1) .\" .\" ============================================================ .\" I tidigare versioner av Linux var dessutom \fBCLONE_NEWPID\fP inte tillåtet (misslyckades med felet \fBEINVAL\fP) i kombination med \fBCLONE_SIGHAND\fP (före Linux 4.3) såväl som \fBCLONE_VM\fP (före Linux 3.12). Ändringarna som lyfte dessa begränsningar har även porterats till tidigare stabila kärnor. .SS "/proc och PID\-namnrymder" Ett \fI/proc\fP\-filsystem visar (i katalogerna \fI/proc/\fPpid) endast processer som är synliga i PID\-namnrymden för processen som utför monteringen, även om \fI/proc\fP visas för processer i andra namnrymder. .PP Efter att ha skapat en ny PID\-namnrymd är det bra för barnet att byta sin rotkatalog och montera en ny procfs\-instans på \fI/proc\fP så att verktyg såsom \fBps\fP(1) fungerar korrekt. Om en ny monteringsnamnrymd skapas samtidigt genom att inkludera \fBCLONE_NEWNS\fP i argumentet \fIflaggor\fP till \fBclone\fP(2) eller \fBunshare\fP(2), då är det inte nödvändigt att byta rotkatalog: en ny procfs\-instans kan monteras direkt över \fI/proc\fP. .PP Från ett skal är kommandot för att montera \fI/proc\fP: .PP .in +4n .EX $ mount \-t proc proc /proc .EE .in .PP .\" .\" ============================================================ .\" Att anropa \fBreadlink\fP(2) på sökvägen \fI/proc/self\fP ger process\-ID:t för anroparen i den procfs\-monteringens PID\-namnrymd (d.v.s., PID\-namnrymden för processen som monterade procfs). Detta kan vara användbart för introspektionsändamål, när en process vill veta sin PID i andra namnrymder. .SS /proc\-filer .TP \fB/proc/sys/kernel/ns_last_pid\fP (från Linux 3.3) .\" commit b8f566b04d3cddd192cfd2418ae6d54ac6353792 Denna fil (som är virtualiserad per PID\-namnrymd) visar den senaste PID:en som allokerades i denna PID\-namnrymd. När nästa PID allokeras kommer kärnan söka efter den lägsta oallokerade PID:en som är större än detta värde, och när denna fil därefter läses kommer den visa den PID:en. .IP .\" This ability is necessary to support checkpoint restore in user-space .\" .\" ============================================================ .\" Denna fil kan skrivas av en process som har förmågan \fBCAP_SYS_ADMIN\fP eller (från Linux 5.9) \fBCAP_CHECKPOINT_RESTORE\fP inuti användarnamnrymden som äger PID\-namnrymden. Detta gör det möjligt att bestämma PID:en som allokeras för nästa process som skapas inuti denna PID\-namnrymd. .SS Diverse När ett process\-ID skickas över ett UNIX\-domänsuttag till en process i en annan PID\-namnrymd (se beskrivningen av \fBSCM_CREDENTIALS\fP i \fBunix\fP(7)) översätts den till det motsvarande PID\-värdet i den mottagande processens PID\-namnrymd. .SH STANDARDER Linux. .SH EXEMPEL Se \fBuser_namespaces\fP(7). .SH "SE ÄVEN" \fBclone\fP(2), \fBreboot\fP(2), \fBsetns\fP(2), \fBunshare\fP(2), \fBproc\fP(5), \fBcapabilities\fP(7), \fBcredentials\fP(7), \fBmount_namespaces\fP(7), \fBnamespaces\fP(7), \fBuser_namespaces\fP(7), \fBswitch_root\fP(8) .PP .SH ÖVERSÄTTNING Den svenska översättningen av denna manualsida skapades av Göran Uddeborg . .PP Denna översättning är fri dokumentation; läs .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE eller senare för upphovsrättsvillkor. Vi tar INGET ANSVAR. .PP Om du hittar fel i översättningen av denna manualsida, skicka ett mail till .MT Tp-sv@listor.tp-sv.se .ME .