<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Container on Nalar</title>
    <link>https://nalar.dev/id/tags/container/</link>
    <description>Recent content in Container on Nalar</description>
    <generator>Hugo</generator>
    <language>id-id</language>
    <lastBuildDate>Sat, 19 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/id/tags/container/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>CLONE_INTO_CGROUP Menempatkan Child ke cgroup Target Saat Dibuat</title>
      <link>https://nalar.dev/id/clone-into-cgroup-menempatkan-child-ke-cgroup-target-saat-dibuat/</link>
      <pubDate>Sat, 19 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/clone-into-cgroup-menempatkan-child-ke-cgroup-target-saat-dibuat/</guid>
      <description>&lt;h1 id=&#34;clone_into_cgroup-menempatkan-child-ke-cgroup-target-saat-dibuat&#34;&gt;CLONE_INTO_CGROUP Menempatkan Child ke cgroup Target Saat Dibuat&lt;/h1&gt;&#xA;&lt;p&gt;Proses yang dibuat di satu cgroup lalu dipindahkan ke cgroup lain memiliki interval singkat tetapi nyata di cgroup awal. Selama interval itu, accounting, resource control, dan freezer state berasal dari penempatan awal, bukan dari tujuan. Linux menyediakan &lt;code&gt;CLONE_INTO_CGROUP&lt;/code&gt; agar &lt;code&gt;clone3()&lt;/code&gt; dapat menempatkan child langsung ke target cgroup v2 sebagai bagian dari pembuatan proses.&lt;/p&gt;&#xA;&lt;p&gt;Mekanisme ini mengubah batas penempatan. Alih-alih membuat task lalu memperbaiki membership cgroup sesudahnya, pemanggil menentukan tujuan sebelum child ada.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Idmapped Mount Memetakan Ulang Ownership Tanpa Menulis Ulang Inode</title>
      <link>https://nalar.dev/id/idmapped-mount-memetakan-ulang-ownership-tanpa-menulis-ulang-inode/</link>
      <pubDate>Sat, 19 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/idmapped-mount-memetakan-ulang-ownership-tanpa-menulis-ulang-inode/</guid>
      <description>&lt;p&gt;Inode yang sama dapat terlihat memiliki ownership berbeda melalui dua mount point tanpa &lt;code&gt;chown()&lt;/code&gt; rekursif. Idmapped mount Linux menempelkan ID mapping pada sebuah mount, sehingga penyajian ownership dan pemeriksaan permission di VFS dapat menerjemahkan user ID serta group ID untuk view tersebut sementara ownership yang disimpan filesystem tetap sama.&lt;/p&gt;&#xA;&lt;p&gt;Properti ini memisahkan metadata inode persisten dari view identitas yang diekspos pada mount tertentu. Mekanisme tersebut berguna ketika satu pohon filesystem perlu dipakai container dengan user namespace yang memetakan ID secara berbeda dari host.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Notifikasi Pengguna seccomp Memindahkan System Call Terpilih ke Supervisor</title>
      <link>https://nalar.dev/id/notifikasi-pengguna-seccomp-memindahkan-system-call-terpilih-ke-supervisor/</link>
      <pubDate>Sat, 19 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/notifikasi-pengguna-seccomp-memindahkan-system-call-terpilih-ke-supervisor/</guid>
      <description>&lt;h1 id=&#34;notifikasi-pengguna-seccomp-memindahkan-system-call-terpilih-ke-supervisor&#34;&gt;Notifikasi Pengguna seccomp Memindahkan System Call Terpilih ke Supervisor&lt;/h1&gt;&#xA;&lt;p&gt;Filter seccomp tidak terbatas pada mengizinkan system call atau menolaknya di kernel. Saat filter mengembalikan &lt;code&gt;SECCOMP_RET_USER_NOTIF&lt;/code&gt;, Linux dapat menahan thread pemanggil lalu mengirim deskripsi system call yang sedang dicoba ke supervisor di user space.&lt;/p&gt;&#xA;&lt;p&gt;Mekanisme ini membentuk batas interposisi untuk call tertentu. Salah satu pemakaiannya adalah saat proses dengan privilege lebih rendah memerlukan operasi yang dimediasi proses lain, misalnya container manager yang menangani call yang tidak dapat dijalankan langsung oleh container. Batas ini sengaja lebih sempit daripada mesin kebijakan keamanan umum: state notifikasi dapat berpacu dengan memori target yang masih dapat berubah, dan dokumentasi kernel memperingatkan agar inspeksi supervisor tidak dijadikan primitive otorisasi.&lt;/p&gt;</description>
    </item>
    <item>
      <title>seccomp User Notification Mendelegasikan Syscall Terpilih ke Supervisor</title>
      <link>https://nalar.dev/id/seccomp-user-notification-mendelegasikan-syscall-terpilih-ke-supervisor/</link>
      <pubDate>Fri, 18 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/seccomp-user-notification-mendelegasikan-syscall-terpilih-ke-supervisor/</guid>
      <description>&lt;h1 id=&#34;seccomp-user-notification-mendelegasikan-syscall-terpilih-ke-supervisor&#34;&gt;seccomp User Notification Mendelegasikan Syscall Terpilih ke Supervisor&lt;/h1&gt;&#xA;&lt;p&gt;Filter seccomp dapat menghentikan system call terpilih sebelum kernel mengeksekusinya, lalu mengirim notifikasi ke supervisor di user space. Thread target tetap terblokir saat supervisor menerima event dan mengirim disposisi. Perilaku ini mengubah hasil filter menjadi handoff terkontrol pada batas kernel dan user space.&lt;/p&gt;&#xA;&lt;p&gt;Mekanismenya adalah &lt;code&gt;SECCOMP_RET_USER_NOTIF&lt;/code&gt;. Berbeda dari action seccomp biasa, filter BPF tidak menyelesaikan keputusan sendirian. Sebuah listener file descriptor menjadi titik koordinasi untuk menerima notifikasi, mengirim respons, dan secara opsional menginjeksi file descriptor.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
