IPC Namespace — Linuxda System V IPC obyektlari va POSIX message queue’larini alohida ko‘rinishga ajratadigan namespace turi. Bir IPC namespace’dagi shared-memory segment, semaphore va message queue identifikatorlari boshqa namespace’dagi processlarga odatda ko‘rinmaydi. Containerlar global IPC nomlari va limitlari bo‘yicha bir-biriga xalaqit bermasligi uchun undan foydalanadi.
Qamrab olinadigan obyektlar
System V shared memory shmget, semaphore semget va message queue msgget orqali yaratiladi. Ular numeric key va ID bilan boshqariladi. IPC namespace key lookup va obyekt jadvalini ajratadi, shuning uchun bir xil key ikki containerda boshqa obyektga bog‘lanadi.
POSIX message queue’lar odatda /dev/mqueue virtual filesystemi orqali ko‘rinadi va IPC namespace bilan bog‘liq. Oddiy POSIX shared memory ko‘pincha tmpfs’dagi fayl sifatida amalga oshadi; uning izolyatsiyasi mount namespace’ga ham tayanadi.
Yaratish va meros
Process clone yoki unshare bilan yangi IPC namespace oladi. Child odatda parentning namespace membershipini meros qiladi. setns orqali mavjud IPC namespace’ga kirish capability va user namespace qoidalariga bog‘liq.
Yangi namespace parentdagi mavjud IPC obyektlarining nusxasini olmaydi; u bo‘sh jadvaldan boshlaydi. Shu jihat mount namespace’dagi daraxt nusxalanishidan farq qiladi.
Lifecycle
System V IPC obyektlari yaratuvchi process tugagach avtomatik yo‘qolmasligi mumkin. Ular explicit remove qilinmaguncha yoki namespace tugaguncha qoladi. Container init cleanup qilmasa limit to‘lishi mumkin. ipcs va ipcrm kabi vositalar to‘g‘ri namespace ichida ishlatilishi kerak.
Shared memoryga attach bo‘lgan processlar mavjud paytda remove flag yangi attachni to‘xtatib, oxirgi detachdan keyin resursni bo‘shatadi. Race va error handling API turiga bog‘liq.
Limit va accounting
Queue hajmi, semaphore soni va shared-memory limitlarining bir qismi namespace bo‘yicha boshqarilishi mumkin, boshqa global kernel resurslari esa hostga umumiy qoladi. Namespace resource isolationning o‘zi emas; memory usage cgroup bilan cheklanadi.
Zararli container ko‘p IPC obyekt yaratib kernel memory sarflashi mumkin. Sysctl limitlari, capability va cgroup birga qo‘llanadi. Host monitoringi barcha namespace’larni ko‘rishi, container ichidagi tool esa faqat o‘z jadvalini ko‘rishi mumkin.
Xavfsizlik va qo‘llanish
IPC obyektlarida owner UID, mode va permission mavjud. User namespace mappingi bu IDlarni container ko‘rinishiga aylantiradi. Namespace chegarasi ichida ham noto‘g‘ri mode begona processga data beradi.
Ikki container ataylab IPC ulashishi kerak bo‘lsa bir xil namespace’dan foydalanishi mumkin. Bu isolationni kamaytiradi va lifecycle coupling yaratadi. Test bir xil key collisioni, namespace exit, limit, permission va cleanupni qamraydi.
Shared IPC rejimi
Bir poddagi containerlar ataylab bir IPC namespace’ni ulashsa System V segment va semaphore orqali tez aloqa qiladi. Bu ularning failure va security chegarasini yaqinlashtiradi: bir container queue’ni olib tashlashi yoki limitni to‘ldirishi mumkin. Obyekt keylari global protokol bilan ajratiladi, permission minimal beriladi va cleanup faqat owner service tomonidan bajariladi.
Restore va checkpoint
Container checkpointida IPC obyekt ID, content, semaphore state va attached processlar saqlanishi kerak. Restore’da ayni numeric IDni olish tashqi collision sabab murakkab bo‘lishi mumkin. Pending message ordering va shared-memory pointerlar address mappingga bog‘liq. Migratsiya vositasi unsupported objectni oldindan rad etadi; qisman tiklangan IPC state bilan applicationni ishga tushirmaydi.
Bog‘liq tushunchalar
System V IPC, shared memory, semaphore, message queue, POSIX mqueue, container isolation