Chroot Grate

[rennergade]

After some discussion with Justin and Rishabh we realized that converting relative paths is very difficult in our current model and that either we have to bloat our TCB or do this in a grate. We're hoping to do the latter.

If we crate a chroot/relative paths grate that lives at the base of lind ie is always the first cage launched: lind-wasm chroot-grate --chroot-dir "lindfs" bash, we can handle both of these scenarios and isolate the filesystems. This is an awesome basic example for the paper as well.

This can just be a stack type grate which makes implementation a bit easier.

Things we'll need:

• initial getcwd call in child before launch to store initial cwd
• hashmap? of cageid's to cwd's for any child cages
• interpose on fork to add new cageids to hashmap
• interpose on chdir/fchdir to update hashmap cwds
• relative path normalization function
• chrooted path as arg to grate
• register handlers for all fs-related path calls to effectively chroot and normalize any paths (see list here: Filesystem Namespace Grate #7 (comment))

[JustinCappos]

This seems like it has a lot built in which may or may not be needed. For example, I'm not sure why we need to know the cwd or why we need to have the hashmap. It seems like the hashmap is only needed when we have multiple children we fork off.

What parts are part of a library (or libraries) and what is specific to this implementation?

[rennergade]

We need the cwd of the calling cage to be able to normalize any relative paths. As far as tracking many children I assume the average case has multiple children or grandchildren?

We can separate the path conversion functions into a library since they'll be useful elsewhere.

[JustinCappos]

Thanks. I was confused about the hashmap (I for some reason read this as chroot instead) but this is clear to me.

I guess you are imagining that the namespace grate would run have its children inherit whatever the parent's provided cwd is by default, right? I guess this is standard for processes, so is logical. I don't think it needs to call this for anything but itself, though. Doesn't it know this for all children?

As a separate consideration, after forking, a child would use chroot to set a root, etc. if you wanted to do something like tmpfs, right?

[rennergade]

I guess you are imagining that the namespace grate would run have its children inherit whatever the parent's provided cwd is by default, right?

Yeah

I guess this is standard for processes, so is logical. I don't think it needs to call this for anything but itself, though. Doesn't it know this for all children?

I'm not sure I'm understanding this part.

As a separate consideration, after forking, a child would use chroot to set a root, etc. if you wanted to do something like tmpfs, right?

Yeah this is a great idea. We won't have chroot implemented at the rawposix layer (ENOSYS or a debug panic?) but can be done through this grate.

[stupendoussuperpowers]

I guess this is standard for processes, so is logical. I don't think it needs to call this for anything but itself, though. Doesn't it know this for all children?

If a cage forks off a child process, that grandchild process's fs calls will be directed back to the chroot-grate instead of its immediate parent. I guess that is why we'd need to keep track of all forked children's cwds. @rennergade correct me if I'm wrong with this mental model.

[JustinCappos]

As a separate consideration, after forking, a child would use chroot to set a root, etc. if you wanted to do something like tmpfs, right?

Yeah this is a great idea. We won't have chroot implemented at the rawposix layer (ENOSYS or a debug panic?) but can be done through this grate.

You could actually have this implemented if you wanted and just have the chroot grate not ever use the reference after the initial call during initialization. chroot calls it receives would not call down to rawposix.

[Yaxuan-w]

During exec, lind-wasm will resolve the executable's path in wasmtime. The chroot grate seems cannot be applied to this case... My thought is to handle this by passing fds in wasmtime runtime: Lind-Project/lind-wasm#656

[JustinCappos]

How does lind-wasm read in the executable? Does wasmtime have the ability to make system calls directly?

…

On Wed, Jan 28, 2026 at 1:32 PM Alice Wen ***@***.***> wrote: *Yaxuan-w* left a comment (Lind-Project/lind-wasm-example-grates#9) <#9 (comment)> During exec, lind-wasm will resolve the executable's path in wasmtime. The chroot grate seems cannot be applied to this case... My thought is to handle this by passing fds in wasmtime runtime: Lind-Project/lind-wasm#656 <Lind-Project/lind-wasm#656> — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD7VEEABHEO25JPY76L4JD6CPAVCNFSM6AAAAACS25G6QWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQMJTGA4DOOJTGA> . You are receiving this because you were assigned.Message ID: ***@***.***>