[youki] Fixing bounding capabilities leak when `config.json` omits the capability set

2026-05-27T00:00:00+00:00
youki</code>'s run</code> and exec</code> paths handled a missing .process.capabilities.bounding</code> inconsistently</li>
youki run</code> didn't touch the bounding capabilities set while youki exec</code> correctly dropped all bounding capabilities</li>
solution is to default unset bounding capabilities to an empty set</li>
</ul>
Comparison table for clarity</h1>
command</th> |</th> reaction to unset bounding</th> |</th> result</th></tr></thead>

! runc run</code></td> |</td> drop all bounding caps</td> |</td> failure (👍)</td></tr>
! youki exec</code></td> |</td> drop all bounding caps</td> |</td> failure (👍)</td></tr>
! youki run</code></td> |</td> don't touch bounding caps</td> |</td> success (should not! 🚨)</td></tr>
</tbody></table>
What are capabilities sets?</h1>
Physically</strong>, they are 5 64-bit bitmasks and each thread (not process) has a set of its own. So each thread carries 320 bits of its capabilities data.
linux:/include/linux/cred.h#L126-L130</a></p>
126</span>kernel_cap_t</span>	cap_inheritable</span>;</span> /*</span> caps our children can inherit </span>*/</span></span>
127</span>kernel_cap_t</span>	cap_permitted</span>;</span>	/*</span> caps we're permitted </span>*/</span></span>
128</span>kernel_cap_t</span>	cap_effective</span>;</span>	/*</span> caps we can actually use </span>*/</span></span>
129</span>kernel_cap_t</span>	cap_bset</span>;</span>	/*</span> capability bounding set </span>*/</span></span>
130</span>kernel_cap_t</span>	cap_ambient</span>;</span>	/*</span> Ambient capability set </span>*/</span></span></code></pre>
Conceptually</strong>, they were introduced to Linux for more granular control over different privileges that historically were tightly coupled to the root user (uid=0).
Thanks to capabilities, we can, for example, give a container's root process the privilege to kill other processes within</strong> the same container (CAP_KILL</code>) without also giving it the right to mount host's file system and escape the container environment (CAP_SYS_ADMIN</code>).
This allows tools like supervisord</code> github:supervisor/supervisor</a> to orchestrate processes inside containers while keeping the host system safe.</p>
Logically</strong>, they are sets of tokens that a thread (a task) can use to prove to the kernel that it is allowed to perform a privileged operation.
On top of that, there are rules describing how these sets affect each other and how processes pass capabilities to their children.</p>
What is the bounding capabilities set?</h1>
Firstly, here's the formula for the permitted set after execve()</code> call: (thread_inheritable & file_inheritable) | (file_permitted & thread_bounding_set) | thread_ambient</code>.</p>
The bounding set acts as the upper hard limit for what capabilities a process can gain through the file_permitted & thread_bounding_set</code> term during execve()</code>. Once a capability is removed from the bounding set, no subsequent execve()</code> can reintroduce it via file permitted capabilities. The one exception is the inheritable path: if the capability was already in the thread's inheritable set before the bounding set was reduced, it can still enter permitted through thread_inheritable & file_inheritable</code> during execve()</code>.</p>
The ambient path thread_ambient</code> won't allow the new thread/process to get the dropped capability either because Linux enforces the invariant that a cap can only be in the ambient set if it's in both permitted and inheritable. Moreover, dropping a cap from the bounding set also clears the cap from the ambient set.</p>
What was the bug in youki</code>?</h1>
The actual bug is pretty simple to spot in the code youki:/crates/libcontainer/src/capabilities.rs#L133-L141</a>:</p>
133</span>///</span> Drop any extra granted capabilities, and reset to defaults which are in oci specification</span></span>
134</span>pub</span> fn</span> drop_privileges</span><</span>S</span>:</span> Syscall</span> +</span> ?</span>Sized</span>></span>(</span></span>
135</span>  cs</span>:</span> &</span>LinuxCapabilities</span>,</span></span>
136</span>  syscall</span>:</span> &</span>S</span>,</span></span>
137</span>)</span> -></span> Result</span><</span>(</span>)</span>,</span> SyscallError</span>></span> {</span></span>
138</span>  //</span> 👀 When bounding is unset `youki` skipped it.</span></span>
139</span>  if</span> let</span> Some</span>(</span>bounding</span>)</span> =</span> cs</span>.</span>bounding</span>(</span>)</span> {</span></span>
140</span>    tracing</span>::</span>debug!</span>(</span>"</span>dropping bounding capabilities to </span>{</span>:?</span>}</span>"</span>,</span> bounding</span>)</span>;</span></span>
141</span>    syscall</span>.</span>set_capability</span>(</span>CapSet</span>::</span>Bounding</span>,</span> &</span>to_set</span>(</span>bounding</span>)</span>)</span>?</span>;</span></span>
142</span>  }</span></span></code></pre>
The solution is clear updated revision</a>:</p>
133</span>///</span> Drop any extra granted capabilities, and reset to defaults which are in oci specification</span></span>
134</span>pub</span> fn</span> drop_privileges</span><</span>S</span>:</span> Syscall</span> +</span> ?</span>Sized</span>></span>(</span></span>
135</span>  cs</span>:</span> &</span>LinuxCapabilities</span>,</span></span>
136</span>  syscall</span>:</span> &</span>S</span>,</span></span>
137</span>)</span> -></span> Result</span><</span>(</span>)</span>,</span> SyscallError</span>></span> {</span></span>
138</span>  let</span> empty_caps</span> =</span> Default</span>::</span>default</span>(</span>)</span>;</span></span>
139</span>  let</span> bounding</span> =</span> cs</span>.</span>bounding</span>(</span>)</span>.</span>as_ref</span>(</span>)</span>.</span>unwrap_or</span>(</span>&</span>empty_caps</span>)</span>;</span></span>
140</span>  tracing</span>::</span>debug!</span>(</span>"</span>dropping bounding capabilities to </span>{</span>:?</span>}</span>"</span>,</span> bounding</span>)</span>;</span></span>
141</span>  syscall</span>.</span>set_capability</span>(</span>CapSet</span>::</span>Bounding</span>,</span> &</span>to_set</span>(</span>bounding</span>)</span>)</span>?</span>;</span></span></code></pre>What about runc</code>?</h1>
They do it mostly the same, except for the ordering of user setup and capability manipulation. runc:/libcontainer/init_linux.go#L340-L366</a></p>
340</span>//</span> drop capabilities in bounding set before changing user</span></span>
341</span>if</span> err</span> :=</span> w</span>.</span>ApplyBoundingSet</span>(</span>)</span>;</span> err</span> !=</span> nil</span> {</span></span>
342</span>  return</span> fmt</span>.</span>Errorf</span>(</span>"</span>unable to apply bounding set: </span>%w</span>"</span>,</span> err</span>)</span></span>
343</span>}</span></span>
344</span>//</span> preserve existing capabilities while we change users</span></span>
345</span>if</span> err</span> :=</span> system</span>.</span>SetKeepCaps</span>(</span>)</span>;</span> err</span> !=</span> nil</span> {</span></span>
346</span>  return</span> fmt</span>.</span>Errorf</span>(</span>"</span>unable to set keep caps: </span>%w</span>"</span>,</span> err</span>)</span></span>
347</span>}</span></span>
348</span>if</span> err</span> :=</span> setupUser</span>(</span>config</span>)</span>;</span> err</span> !=</span> nil</span> {</span></span>
349</span>  return</span> fmt</span>.</span>Errorf</span>(</span>"</span>unable to setup user: </span>%w</span>"</span>,</span> err</span>)</span></span>
350</span>}</span></span>
351</span>//</span> Change working directory AFTER the user has been set up, if we haven't done it yet.</span></span>
352</span>if</span> doChdir</span> {</span></span>
353</span>  if</span> err</span> :=</span> unix</span>.</span>Chdir</span>(</span>config</span>.</span>Cwd</span>)</span>;</span> err</span> !=</span> nil</span> {</span></span>
354</span>    return</span> fmt</span>.</span>Errorf</span>(</span>"</span>chdir to cwd (</span>%q</span>) set in config.json failed: </span>%w</span>"</span>,</span> config</span>.</span>Cwd</span>,</span> err</span>)</span></span>
355</span>  }</span></span>
356</span>}</span></span>
357</span>//</span> Make sure our final working directory is inside the container.</span></span>
358</span>if</span> err</span> :=</span> verifyCwd</span>(</span>)</span>;</span> err</span> !=</span> nil</span> {</span></span>
359</span>  return</span> err</span></span>
360</span>}</span></span>
361</span>if</span> err</span> :=</span> system</span>.</span>ClearKeepCaps</span>(</span>)</span>;</span> err</span> !=</span> nil</span> {</span></span>
362</span>  return</span> fmt</span>.</span>Errorf</span>(</span>"</span>unable to clear keep caps: </span>%w</span>"</span>,</span> err</span>)</span></span>
363</span>}</span></span>
364</span>if</span> err</span> :=</span> w</span>.</span>ApplyCaps</span>(</span>)</span>;</span> err</span> !=</span> nil</span> {</span></span>
365</span>  return</span> fmt</span>.</span>Errorf</span>(</span>"</span>unable to apply caps: </span>%w</span>"</span>,</span> err</span>)</span></span>
366</span>}</span></span></code></pre>Further reading</h1>

The Linux Kernel documentation: Credentials in Linux > Types of Credentials</a></li>
Kernel Archive: Linux Capabilities FAQ 0.2</a></li>
Kernel Archive: Linux-Privs (DRAFT v0.10 1997/4/21)</a></li>
</ul>


[youki] Fixing readonly rootfs in rootless containers when NODEV/NOEXEC/NOSUID are set
2026-05-18T00:00:00+00:00


issue: #3517:[root.readonly: true] does not work on filesystems mounted with nodev or nosuid in usernamespace</a></li>
fix: #3536:preserve mount flags for readonly remount of rootfs in init</a></li>
</ul>
</blockquote>
TL;DR</h1>

youki</code> forgot about original mount flags of the filesystem it was trying to remount</li>
in rootless containers</abbr> Linux locks</a> some of these mount flags</a> down for security reasons</li>
when Linux sees that youki</code>'s init process tries to remount rootfs and drop locked flags it throws EPERM</code></a></li>
solution is to include the original mount flags to the remount call</li>
</ul>
How did</u> youki handle root.readonly: true</code>?</h1>
youki:crates/libcontainer/src/process/init/process.rs#L199-L213</a>:</p>
199</span>if</span> matches!</span>(</span>args</span>.</span>container_type</span>,</span> ContainerType</span>::</span>InitContainer</span>)</span> {</span></span>
200</span>  if</span> ctx</span>.</span>rootfs_ro </span>{</span></span>
201</span>    ctx</span>.</span>syscall</span></span>
202</span>      .</span>mount</span>(</span></span>
203</span>        None</span>,</span></span>
204</span>        Path</span>::</span>new</span>(</span>"</span>/</span>"</span>)</span>,</span></span>
205</span>        None</span>,</span></span>
206</span>        //</span> 👀 Notice how it didn't bother about</span></span>
207</span>        //</span> 👀 any of the original mount flags</span></span>
208</span>        MsFlags</span>::</span>MS_RDONLY</span> |</span> MsFlags</span>::</span>MS_REMOUNT</span> |</span> MsFlags</span>::</span>MS_BIND</span>,</span></span>
209</span>        None</span>,</span></span>
210</span>      )</span></span>
211</span>      .</span>map_err</span>(</span>|</span>err</span>|</span> {</span></span>
212</span>        tracing</span>::</span>error!</span>(</span>?</span>err</span>,</span> "</span>failed to remount root `/` as readonly</span>"</span>)</span>;</span></span>
213</span>        InitProcessError</span>::</span>SyscallOther</span>(</span>err</span>)</span></span>
214</span>      }</span>)</span>?</span>;</span></span>
215</span>  }</span></span></code></pre>
This works perfectly for rootful containers run by a user with the CAP_SYS_ADMIN</code> capability (youki</code> resets effective and drops capabilities a little bit later in the flow</a>).</p>
But for rootless</strong> containers, a new user namespace is always created and Linux locks some of the mount flags in this case.
It makes sense because we generally don't want a subordinate user namespace to be able to drop our security restrictions.</p>
When these flags are locked, an attempt to remount without these flags gets EPERM</code> from the kernel.</p>
linux:/fs/namespace.c#L3326-L3344</a>:</p>
3326</span>/*</span></span>
3327</span> * Handle reconfiguration of the mountpoint only without alteration of the</span></span>
3328</span> * superblock it refers to.  This is triggered by specifying MS_REMOUNT|MS_BIND</span></span>
3329</span> * to mount(2).</span></span>
3330</span> */</span></span>
3331</span>static</span> int</span> do_reconfigure_mnt</span>(</span>const</span> struct</span> path </span>*</span>path</span>,</span> unsigned</span> int</span> mnt_flags</span>)</span></span>
3332</span>{</span></span>
3333</span>  struct</span> super_block </span>*</span>sb </span>=</span> path</span>-></span>mnt</span>-></span>mnt_sb</span>;</span></span>
3334</span>  struct</span> mount </span>*</span>mnt </span>=</span> real_mount</span>(</span>path</span>-></span>mnt</span>)</span>;</span></span>
3335</span>  int</span> ret</span>;</span></span>
3336</span></span>
3337</span>  if</span> (</span>!</span>check_mnt</span>(</span>mnt</span>)</span>)</span></span>
3338</span>    return</span> -</span>EINVAL</span>;</span></span>
3339</span></span>
3340</span>  if</span> (</span>!</span>path_mounted</span>(</span>path</span>)</span>)</span></span>
3341</span>    return</span> -</span>EINVAL</span>;</span></span>
3342</span></span>
3343</span>  //</span> 👀</span></span>
3344</span>  if</span> (</span>!</span>can_change_locked_flags</span>(</span>mnt</span>,</span> mnt_flags</span>)</span>)</span></span>
3345</span>    return</span> -</span>EPERM</span>;</span></span></code></pre>
linux:/fs/namespace.c#L3242-L3273</a></p>
3242</span>/*</span></span>
3243</span> * Don't allow locked mount flags to be cleared.</span></span>
3244</span> *</span></span>
3245</span> * No locks need to be held here while testing the various MNT_LOCK</span></span>
3246</span> * flags because those flags can never be cleared once they are set.</span></span>
3247</span> */</span></span>
3248</span>static</span> bool</span> can_change_locked_flags</span>(</span>struct</span> mount </span>*</span>mnt</span>,</span> unsigned</span> int</span> mnt_flags</span>)</span></span>
3249</span>{</span></span>
3250</span>	unsigned</span> int</span> fl </span>=</span> mnt</span>-></span>mnt</span>.</span>mnt_flags</span>;</span></span>
3251</span></span>
3252</span>	if</span> (</span>(</span>fl </span>&</span> MNT_LOCK_READONLY</span>)</span> &&</span></span>
3253</span>	  !</span>(</span>mnt_flags </span>&</span> MNT_READONLY</span>)</span>)</span></span>
3254</span>		return</span> false</span>;</span></span>
3255</span></span>
3256</span>	if</span> (</span>(</span>fl </span>&</span> MNT_LOCK_NODEV</span>)</span> &&</span></span>
3257</span>	  !</span>(</span>mnt_flags </span>&</span> MNT_NODEV</span>)</span>)</span></span>
3258</span>		return</span> false</span>;</span></span>
3259</span></span>
3260</span>	if</span> (</span>(</span>fl </span>&</span> MNT_LOCK_NOSUID</span>)</span> &&</span></span>
3261</span>	  !</span>(</span>mnt_flags </span>&</span> MNT_NOSUID</span>)</span>)</span></span>
3262</span>		return</span> false</span>;</span></span>
3263</span></span>
3264</span>	if</span> (</span>(</span>fl </span>&</span> MNT_LOCK_NOEXEC</span>)</span> &&</span></span>
3265</span>	  !</span>(</span>mnt_flags </span>&</span> MNT_NOEXEC</span>)</span>)</span></span>
3266</span>		return</span> false</span>;</span></span>
3267</span></span>
3268</span>	if</span> (</span>(</span>fl </span>&</span> MNT_LOCK_ATIME</span>)</span> &&</span></span>
3269</span>	  (</span>(</span>fl </span>&</span> MNT_ATIME_MASK</span>)</span> !=</span> (</span>mnt_flags </span>&</span> MNT_ATIME_MASK</span>)</span>)</span>)</span></span>
3270</span>		return</span> false</span>;</span></span>
3271</span></span>
3272</span>	return</span> true</span>;</span></span>
3273</span>}</span></span></code></pre>
linux:/fs/namespace.c#L2412-L2437</a>:</p>
2412</span>static</span> void</span> lock_mnt_tree</span>(</span>struct</span> mount </span>*</span>mnt</span>)</span></span>
2413</span>{</span></span>
2414</span>  struct</span> mount </span>*</span>p</span>;</span></span>
2415</span></span>
2416</span>  for</span> (</span>p </span>=</span> mnt</span>;</span> p</span>;</span> p </span>=</span> next_mnt</span>(</span>p</span>,</span> mnt</span>)</span>)</span> {</span></span>
2417</span>    int</span> flags </span>=</span> p</span>-></span>mnt</span>.</span>mnt_flags</span>;</span></span>
2418</span>    /*</span> Don't allow unprivileged users to change mount flags </span>*/</span></span>
2419</span>    flags </span>|=</span> MNT_LOCK_ATIME</span>;</span></span>
2420</span></span>
2421</span>    if</span> (</span>flags </span>&</span> MNT_READONLY</span>)</span></span>
2422</span>      flags </span>|=</span> MNT_LOCK_READONLY</span>;</span></span>
2423</span></span>
2424</span>    if</span> (</span>flags </span>&</span> MNT_NODEV</span>)</span></span>
2425</span>      flags </span>|=</span> MNT_LOCK_NODEV</span>;</span></span>
2426</span></span>
2427</span>    if</span> (</span>flags </span>&</span> MNT_NOSUID</span>)</span></span>
2428</span>      flags </span>|=</span> MNT_LOCK_NOSUID</span>;</span></span>
2429</span></span>
2430</span>    if</span> (</span>flags </span>&</span> MNT_NOEXEC</span>)</span></span>
2431</span>      flags </span>|=</span> MNT_LOCK_NOEXEC</span>;</span></span>
2432</span>    /*</span> Don't allow unprivileged users to reveal what is under a mount </span>*/</span></span>
2433</span>    if</span> (</span>list_empty</span>(</span>&</span>p</span>-></span>mnt_expire</span>)</span> &&</span> p </span>!=</span> mnt</span>)</span></span>
2434</span>      flags </span>|=</span> MNT_LOCKED</span>;</span></span>
2435</span>    p</span>-></span>mnt</span>.</span>mnt_flags</span> =</span> flags</span>;</span></span>
2436</span>  }</span></span>
2437</span>}</span></span></code></pre>
Usage examples show us that the lock is placed when a mount is cloned across a user namespace boundary:</p>

linux:/fs/namespace.c#L2637-L2639</a>2637</span>/*</span> Notice when we are propagating across user namespaces </span>*/</span></span>
2638</span>if</span> (</span>child</span>-</span>></span>mnt_parent</span>-</span>></span>mnt_ns</span>-</span>></span>user_ns </span>!=</span> user_ns</span>)</span></span>
2639</span>  lock_mnt_tree</span>(</span>child</span>)</span>;</span></span></code></pre></li>
linux:/fs/namespace.c#L3156-L3162</a>3156</span>/*</span></span>
3157</span> * now mount the detached tree on top of the copy</span></span>
3158</span> * of the real rootfs we created.</span></span>
3159</span> */</span></span>
3160</span>attach_mnt</span>(</span>mnt</span>,</span> new_ns_root</span>,</span> mp.mp</span>)</span>;</span></span>
3161</span>if</span> (</span>user_ns </span>!=</span> ns</span>-</span>></span>user_ns</span>)</span></span>
3162</span>  lock_mnt_tree</span>(</span>new_ns_root</span>)</span>;</span></span></code></pre></li>
linux:/fs/namespace.c#L4266-L4270</a>4266</span>if</span> (</span>user_ns </span>!=</span> ns</span>-</span>></span>user_ns</span>)</span> {</span></span>
4267</span>  guard</span>(</span>mount_writer</span>)</span>(</span>)</span>;</span></span>
4268</span>  lock_mnt_tree</span>(</span>new</span>)</span>;</span></span>
4269</span>}</span></span>
4270</span>new_ns</span>-</span>></span>root </span>=</span> new</span>;</span></span></code></pre></li>
</ul>
How does</u> youki handle root.readonly: true</code> after fix?</h1>
youki:crates/libcontainer/src/process/init/process.rs#L201-L225</a>:</p>
201</span>if</span> matches!</span>(</span>args</span>.</span>container_type</span>,</span> ContainerType</span>::</span>InitContainer</span>)</span> {</span></span>
202</span>  if</span> ctx</span>.</span>rootfs_ro </span>{</span></span>
203</span>    //</span> 👀 Here we get the original mount flags ...</span></span>
204</span>    let</span> current_flags</span> =</span> statfs</span>(</span>"</span>/</span>"</span>)</span></span>
205</span>      .</span>map_err</span>(</span>|</span>err</span>|</span> {</span></span>
206</span>        tracing</span>::</span>error!</span>(</span>?</span>err</span>,</span> "</span>failed to statfs root '/' to get current mount flags</span>"</span>)</span>;</span></span>
207</span>        InitProcessError</span>::</span>SyscallOther</span>(</span>SyscallError</span>::</span>Nix</span>(</span>err</span>)</span>)</span></span>
208</span>      }</span>)</span>?</span></span>
209</span>      .</span>flags</span>(</span>)</span></span>
210</span>      .</span>bits</span>(</span>)</span>;</span></span>
211</span>    ctx</span>.</span>syscall</span></span>
212</span>      .</span>mount</span>(</span></span>
213</span>        None</span>,</span></span>
214</span>        Path</span>::</span>new</span>(</span>"</span>/</span>"</span>)</span>,</span></span>
215</span>        None</span>,</span></span>
216</span>        MsFlags</span>::</span>MS_RDONLY</span></span>
217</span>          |</span> MsFlags</span>::</span>MS_REMOUNT</span></span>
218</span>          |</span> MsFlags</span>::</span>MS_BIND</span></span>
219</span>          //</span> 👀 ... and here we reuse them!</span></span>
220</span>          |</span> MsFlags</span>::</span>from_bits_truncate</span>(</span>current_flags</span>)</span>,</span></span>
221</span>        None</span>,</span></span>
222</span>      )</span></span>
223</span>      .</span>map_err</span>(</span>|</span>err</span>|</span> {</span></span>
224</span>        tracing</span>::</span>error!</span>(</span>?</span>err</span>,</span> "</span>failed to remount root `/` as readonly</span>"</span>)</span>;</span></span>
225</span>        InitProcessError</span>::</span>SyscallOther</span>(</span>err</span>)</span></span>
226</span>      }</span>)</span>?</span>;</span></span>
227</span>  }</span></span></code></pre>A note on youki</code>'s testing infrastructure</h1>
youki</code> has a really nice testing framework called contest</code>.
It makes it very easy to set up fixtures and hook into a container before the init process enters it.</p>
It also allows hooking inside the container using runtimetest</code> static binary which is compiled with a set
of validators which are just simple functions that execute some checks and may output something into stderr</code>
which indicates a validation failure.</p>
youki:/tests/contest/contest/src/tests/root_readonly_true/root_readonly_tests.rs#L31-L63</a>:</p>
31</span>fn</span> root_readonly_true_in_userns_test</span>(</span>)</span> -></span> TestResult</span> {</span></span>
32</span>  //</span> 👀 Here we get the effective user under which the test-runner itself is running.</span></span>
33</span>  //</span> 👀 We need it to safely map the user inside the new container's user namespace to our user.</span></span>
34</span>  let</span> uid</span> =</span> nix</span>::</span>unistd</span>::</span>geteuid</span>(</span>)</span>.</span>as_raw</span>(</span>)</span>;</span></span>
35</span>  let</span> gid</span> =</span> nix</span>::</span>unistd</span>::</span>getegid</span>(</span>)</span>.</span>as_raw</span>(</span>)</span>;</span></span>
36</span>  let</span> mut</span> spec</span> =</span> Spec</span>::</span>rootless</span>(</span>uid</span>,</span> gid</span>)</span>;</span></span>
37</span>  //</span> 👀 Set readonly to `true`</span></span>
38</span>  spec</span>.</span>set_root</span>(</span>RootBuilder</span>::</span>default</span>(</span>)</span>.</span>readonly</span>(</span>true</span>)</span>.</span>build</span>(</span>)</span>.</span>ok</span>(</span>)</span>)</span></span>
39</span>    .</span>set_process</span>(</span></span>
40</span>      ProcessBuilder</span>::</span>default</span>(</span>)</span></span>
41</span>        //</span> 👀 Here I use `root_readonly` validator that is already made by someone else:</span></span>
42</span>        //</span> 👀 https://github.com/YawKar/youki/blob/e4b4896c6dbfd28270e11beb73e4799d7317556c/tests/contest/runtimetest/src/main.rs#L50</span></span>
43</span>        .</span>args</span>(</span>vec!</span>[</span>"</span>runtimetest</span>"</span>.</span>to_string</span>(</span>)</span>,</span> "</span>root_readonly</span>"</span>.</span>to_string</span>(</span>)</span>]</span>)</span></span>
44</span>        .</span>build</span>(</span>)</span></span>
45</span>        .</span>ok</span>(</span>)</span>,</span></span>
46</span>    )</span>;</span></span>
47</span>  test_inside_container</span>(</span>&</span>spec</span>,</span> &</span>CreateOptions</span>::</span>default</span>(</span>)</span>,</span> &</span>|</span>rootfs</span>:</span> &</span>Path</span>|</span> {</span></span>
48</span>    //</span> Bind-mount the rootfs onto itself with MS_NODEV | MS_NOSUID, simulating a</span></span>
49</span>    //</span> filesystem that has those flags locked (the typical case in user namespaces).</span></span>
50</span>    //</span> Without the fix for #3517, the subsequent readonly remount would fail with</span></span>
51</span>    //</span> EPERM because the kernel rejects dropping these flags in a user namespace.</span></span>
52</span>    //</span> 👀 Here's why we need 2 mount calls:</span></span>
53</span>    //</span> 👀 Initially '/' is just a directory inside the container namespace.</span></span>
54</span>    //</span> 👀 Linux doesn't allow mount() calls on directories.</span></span>
55</span>    //</span> 👀 We need to MS_BIND '/' to make a mount point out of it.</span></span>
56</span>    nix</span>::</span>mount</span>::</span>mount</span>(</span></span>
57</span>      Some</span>(</span>rootfs</span>)</span>,</span></span>
58</span>      rootfs</span>,</span></span>
59</span>      None</span>::</span><</span>&</span>str</span>></span>,</span></span>
60</span>      MsFlags</span>::</span>MS_BIND</span>,</span></span>
61</span>      None</span>::</span><</span>&</span>str</span>></span>,</span></span>
62</span>    )</span>?</span>;</span></span>
63</span>    //</span> 👀 Now that we have a mount point we are free to modify mount flags!</span></span>
64</span>    nix</span>::</span>mount</span>::</span>mount</span>(</span></span>
65</span>      Some</span>(</span>rootfs</span>)</span>,</span></span>
66</span>      rootfs</span>,</span></span>
67</span>      None</span>::</span><</span>&</span>str</span>></span>,</span></span>
68</span>      MsFlags</span>::</span>MS_REMOUNT</span> |</span> MsFlags</span>::</span>MS_BIND</span> |</span> MsFlags</span>::</span>MS_NODEV</span> |</span> MsFlags</span>::</span>MS_NOSUID</span>,</span></span>
69</span>      None</span>::</span><</span>&</span>str</span>></span>,</span></span>
70</span>    )</span>?</span>;</span></span>
71</span>    Ok</span>(</span>(</span>)</span>)</span></span>
72</span>  }</span>)</span></span>
73</span>}</span></span></code></pre>
You can read more about it here: Youki Developer docs: Contest</a>.</p>


[troubleshoot] Where did my core dumps go? Catching PhantomJS zeroing RLIMIT_CORE
2026-03-30T00:00:00+00:00
TL;DR</h1>

configured RLIMIT_CORE</code> on the container's root process to 40 GiB (prlimit -c $(( 40 * 1024 * 1024 * 1024 ))</code>)</li>
yet got no core dumps when PhantomJS process terminated itself with SIGABRT</code></li>
the core dump handler registered in /proc/sys/kernel/core_pattern</code> logged that %c</code> (core file size soft resource limit) was 0</code></li>
turned out (under gdb</code>) PhantomJS makes a setrlimit</code> call effectively zeroing its RLIMIT_CORE</code></li>
</ul>
The problem</h1>
A cybersecurity engineer from a team that uses PhantomJS for their automated vulnerability analysis came to me with a problem.
From time to time the PhantomJS process in their pods crashed badly, mostly with SIGABRT</code>.
He couldn't understand where his core dumps went and asked me to help him find out.</p>
I entered the container and found the parent process. It was a Go application that ran PhantomJS via execve()</code> as part of its job. Indeed, no core dumps were found in /coredumps</code> directory where our core dump handler normally places them.</p>
First clue: core dump handler says %c = 0</code></h1>
In the logs of the core dump handler I saw that it logged 0</code> instead of 42949672960</code> (which corresponds to 40GiB) under %c</code> in core_pattern</code>, which stands for the core file size soft limit.</p>

/proc/sys/kernel/core_pattern</code> is just a command that Linux pipes a fresh core dump to, while also giving it some arguments describing the core and the crashed process. It typically looks like this: |/usr/lib/coredump-handler -c %c -p %p -e %e</code>. Linux substitutes %c %p %e</code> and so on. %e</code> is substituted by first 15 characters of the executable filename. More on that in man 5 core</code>.
It instantly made me suspect problems with RLIMIT_CORE</code> as this is the limit that Linux kernel's dumper takes into account when handling SIGABRT</code> (and other signals with default signal action SIG_DFL</code> to dump a core).</p>
</blockquote>
Finding the binary</h1>
I straced the process to find the path to the PhantomJS binary it's trying to run.</p>
$</span> sudo</span> strace</span> -</span>f</span> -</span>e</span> execve</span> -</span>p</span> $(</span>pgrep</span> the-go-application-name</span>)</span></span>
#</span> ...</span></span>
[</span>pid 259132</span>]</span> execve(</span>"</span>/usr/bin/phantomjs/phantomjs</span>"</span>,</span> [</span>"</span>phantomjs</span>"</span>,</span> ...],</span> 0x55858e2a6d70</span> /</span>*</span> 126</span> vars</span> *</span>/</span>) = 0</span></span>
#</span> ...</span></span></code></pre>Verifying that limits propagate correctly</h1>
After that I stepped into gdb</code> that was available on the host. I wanted to see if prlimit -c -p $(pgrep phantomjs)</code> changed somehow from my session's ulimit in order to check that propagation of limits worked as expected.</p>
#</span> Set RLIMIT_CORE for my current session</span></span>
$</span> ulimit</span> -</span>c</span> 123456</span></span>
#</span> Check that it's set</span></span>
$</span> ulimit</span> -</span>c</span></span>
123456</span></span>
#</span> Check that the limit is indeed propagating to child processes</span></span>
$</span> echo</span> "</span>Current process: </span>$</span>$</span>"</span> &&</span> bash</span> -</span>c</span> '</span>echo "Child process: $$" && ulimit -c</span>'</span></span>
Current</span> process:</span> 303405</span></span>
Child</span> process:</span> 303408</span></span>
123456</span></span>
#</span> Now run the phantomjs binary under gdb</span></span>
$</span> gdb</span> -</span>q</span> /usr/bin/phantomjs/phantomjs</span></span>
Reading</span> symbols</span> from</span> /usr/bin/phantomjs/phantomjs...</span></span>
(</span>No</span> debugging</span> symbols</span> found</span> in</span> /usr/bin/phantomjs/phantomjs</span>)</span></span>
(</span>gdb</span>)</span> #</span> Add breakpoint to standard `_start` symbol entrypoint</span></span>
(</span>gdb</span>)</span> break</span> _start</span></span>
Function</span> "</span>_start</span>"</span> not</span> defined.</span></span>
Make</span> breakpoint</span> pending</span> on</span> future</span> shared</span> library</span> load?</span> (y</span> or</span> [n</span>]) y</span></span>
Breakpoint</span> 1</span> (_start</span>) pending.</span></span>
(</span>gdb</span>)</span> run</span></span>
Starting</span> program:</span> /usr/bin/phantomjs/phantomjs</span> </span></span>
</span>
Breakpoint</span> 1,</span> 0x00007ffff7fe3d40</span> in</span> _start</span> (</span>) from /lib64/ld-linux-x86-64.so.2</span></span>
(</span>gdb</span>)</span> #</span> Let's get the PID of the inferior process to then see the limits</span></span>
(</span>gdb</span>)</span> info</span> proc</span></span>
process</span> 33913</span></span>
cmdline</span> =</span> '</span>/usr/bin/phantomjs/phantomjs</span>'</span></span>
cwd</span> =</span> '</span>/</span>'</span></span>
exe</span> =</span> '</span>/usr/bin/phantomjs/phantomjs</span>'</span></span>
(</span>gdb</span>)</span> shell</span> cat</span> /proc/33913/limits</span> |</span> grep</span> core</span></span>
Max</span> core</span> file</span> size</span>        126418944</span>            126418944</span>            bytes</span>     </span></span>
(</span>gdb</span>)</span> shell</span> echo</span> $(</span>(</span>126418944</span> /</span> 1024</span>)</span>)</span></span>
123456</span></span>
(</span>gdb</span>)</span> quit</span></span></code></pre>
So the limit arrives correctly. Something inside PhantomJS changes it.</p>
Catching the culprit</h1>
There's a known syscall that allows programs to set these limits: setrlimit</code> (man 2 setrlimit</code>).
Code from the manpage:</p>
#</span>include</span> <</span>sys/resource.h</span>></span></span>
</span>
int</span> getrlimit</span>(</span>int</span> resource</span>,</span> struct</span> rlimit </span>*</span>rlim</span>)</span>;</span></span>
int</span> setrlimit</span>(</span>int</span> resource</span>,</span> const</span> struct</span> rlimit </span>*</span>rlim</span>)</span>;</span></span>
</span>
int</span> prlimit</span>(</span>pid_t</span> pid</span>,</span> int</span> resource</span>,</span></span>
const</span> struct</span> rlimit </span>*</span>_Nullable </span>new_limit</span>,</span></span>
struct</span> rlimit </span>*</span>_Nullable </span>old_limit</span>)</span>;</span></span>
</span>
struct</span> rlimit </span>{</span></span>
    rlim_t</span>  rlim_cur</span>;</span>  /*</span> Soft limit </span>*/</span></span>
    rlim_t</span>  rlim_max</span>;</span>  /*</span> Hard limit (ceiling for rlim_cur) </span>*/</span></span>
}</span>;</span></span>
</span>
typedef</span> /*</span> ... </span>*/</span>  rlim_t</span>;</span>  /*</span> Unsigned integer type </span>*/</span></span></code></pre>
If I can catch PhantomJS calling this syscall then I can see what it sets as its new RLIMIT_CORE</code>.
Let's see the actual setrlimit</code> call:</p>
$</span> gdb</span> -</span>q</span> /usr/bin/phantomjs/phantomjs</span></span>
Reading</span> symbols</span> from</span> /usr/bin/phantomjs/phantomjs...</span></span>
(</span>No</span> debugging</span> symbols</span> found</span> in</span> /usr/bin/phantomjs/phantomjs</span>)</span></span>
(</span>gdb</span>)</span> break</span> setrlimit</span></span>
Breakpoint</span> 1</span> at</span> 0x18e10</span></span>
(</span>gdb</span>)</span> run</span></span>
Starting</span> program:</span> /usr/bin/phantomjs/phantomjs</span></span>
[</span>Thread debugging using libthread_db enabled</span>]</span></span>
Using</span> host</span> libthread_db</span> library</span> "</span>/lib/x86_64-linux-gnu/libthread_db.so.1</span>"</span>.</span></span>
</span>
Breakpoint</span> 1,</span> __setrlimit64</span> (resource=RLIMIT_CORE,</span> rlimits=</span>0x7fffffffe160</span>) at ../sysdeps/unix/sysv/linux/setrlimit64.c:38</span></span>
38</span>      ../sysdeps/unix/sysv/linux/setrlimit64.c:</span> No</span> such</span> file</span> or</span> directory.</span></span>
(</span>gdb</span>)</span> #</span> Got it! Now need to pretty print the actual value</span></span>
(</span>gdb</span>)</span> info</span> args</span></span>
resource</span> =</span> RLIMIT_CORE</span></span>
rlimits</span> =</span> 0x7fffffffe160</span></span>
(</span>gdb</span>)</span> print</span> *</span>(</span>struct</span> rlimit</span> *</span>)</span>0x7fffffffe160</span></span>
$</span>1</span> = {</span>rlim_cur</span> =</span> 0,</span> rlim_max</span> =</span> 0</span>}</span></span>
(</span>gdb</span>)</span> #</span> 🎉</span></span></code></pre>
With this we can finally state that PhantomJS sets its own RLIMIT_CORE</code> to 0</code> on startup.
And that's exactly the reason why no core dumps are produced.</p>
Conclusion</h1>
I showed the cybersec guy these outputs and explained what the problem was, warned him about the deprecation of PhantomJS.
The fix path was either patching PhantomJS's startup behavior (LD_PRELOAD</code> a small injection that ignores setrlimit</code> calls with RLIMIT_CORE</code>) or migrating to a maintained headless browser (PhantomJS has been deprecated since 2018).</p>
Note</h1>
Although I used gdb to catch the setrlimit</code> call, I could have caught it more easily with strace</code>. I used gdb</code> mostly because at the time I wasn't sure setrlimit</code> was the culprit.</p>
Special thanks</h1>
A special thanks to my friend Yuri Fomichev who gave me an opportunity to troubleshoot this!</p>
Further reading</h1>

man 5 core</code> for the part about when core dump is not produced and how to use /proc/sys/kernel/core_pattern</code></li>
man 7 signal</code> for table of default signal actions, such as core</code> dump, term</code>inate, ign</code>ore, stop</code> and cont</code>inue.</li>
</ul>


[Gallery] DOSBox: Hello, Yawkar
2026-02-15T00:00:00+00:00







Original author: Zarina Sharipova.</p>
yawkar's blog

[youki] Fixing bounding capabilities leak when `config.json` omits the capability set

[youki] Fixing readonly rootfs in rootless containers when NODEV/NOEXEC/NOSUID are set

TL;DR</h1> youki</code> forgot about original mount flags of the filesystem it was trying to remount</li>

[troubleshoot] Where did my core dumps go? Catching PhantomJS zeroing RLIMIT_CORE

[Gallery] DOSBox: Hello, Yawkar
