Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fence off txhashset validation in its own process #2741

Open
ignopeverell opened this issue Apr 10, 2019 · 10 comments
Open

Fence off txhashset validation in its own process #2741

ignopeverell opened this issue Apr 10, 2019 · 10 comments

Comments

@ignopeverell
Copy link
Contributor

When downloaded from the network on sync, a txhashset archive should be handled with more care than we do now, as it could be forged to mess things up in all sorts of ways. We should fence this off in a different process until the validation code is completely happy with what we were provided. Something like chroot, that limits the hard drive visibility of the forked process would also be great but may be hard to achieve across platforms.

@chisa0a
Copy link

chisa0a commented Apr 19, 2019

Found this after quick search: libjail-rs.

I'd be willing to dig into this issue, if no one else has started on it.

@chisa0a
Copy link

chisa0a commented Apr 20, 2019

After reading a bit of their docs, libjail-rs requires root.

Found uchroot in python, but it's in python... maybe can adapt their techniques?

Somewhat new to Rust, so will keep searching.

@ignopeverell
Copy link
Contributor Author

Perfect, thanks for looking into this.

@chisa0a
Copy link

chisa0a commented Apr 20, 2019

No worries.

Found a couple more promising crates:

Both are actively maintained, and are user-space. Will read through the code, suspect it is nice.

@0xmichalis
Copy link
Contributor

Please make sure any solution gets tested with a containerized grin node too

@chisa0a
Copy link

chisa0a commented Apr 20, 2019

Please make sure any solution gets tested with a containerized grin node too

Will do. Also found fuse in my searches, which looks like all that may be needed. Going to experiment a bit, and see what works.

@chisa0a
Copy link

chisa0a commented Apr 24, 2019

AFAICT so far, implementing a FUSE filesystem will take some work using rust-fuse as a library crate.

They have a low-level API based on libfuse's low-level API, but using those interfaces externally isn't obvious to me. It seems meant to be used as a CLI tool to mount a FUSE filesystem, then do stuff in the mounted fs, but idk.

sandboxfs uses rust-fuse internally, and also appears to be intended as a CLI tool, maybe that's enough.

There is an issue open for Windows support via Dokan in rust-fuse, but atm the crate is *nix + mac only.

What are some more seasoned opinions on how to move forward?

@ignopeverell
Copy link
Contributor Author

That sounds like quite a bit of work and several large dependencies. Part of the goal is to limit our exposure to those, so I'm not sure we should go with something as complex of a full FUSE filesystem. How about starting with process isolation, which seems like the more tractable problem?

@chisa0a
Copy link

chisa0a commented Apr 25, 2019

so I'm not sure we should go with something as complex of a full FUSE filesystem

100% in agreement, why I wanted to just use a minimal set of the rust-fuse API, but atm that doesn't seem feasible.

How about starting with process isolation, which seems like the more tractable problem?

Will look into it. That's what I started searching for, and somehow got lost down the FUSE rabbit-hole.

If you are talking about forking a child process, and doing all the txhashset processing in there, will try to get something working.

Will continue the search.

@chisa0a
Copy link

chisa0a commented May 10, 2019

Small update: found Servo's ipc-channel for IPC, which seems like the most mature solution out of Rust crates. No Windows-native support atm, but it's being worked on.

Will post a WIP PR once something is working on Linux.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants