Handle binary for shebangs

[jyn514]

Addresses #8.

The code here is really not fun, but that's because dealing with binary strings in rust is really not fun.
Note that this introduces a dependency on BString so I didn't have to deal with turning a Vec<u8> into OsString which appears to be non-trivial.
Note that this will crash on windows for binary files, not sure if the project plans to run on windows.

The following tests now pass because of this pull:

• test kernel::execve::shebang::tests::test_extract_shebang_not_script
• test kernel::execve::shebang::tests::test_expand_shebang_not_script

[jyn514]

Note: the reason dealing with binary in the first place is important is for files that aren't scripts, e.g. /bin/sleep. If we're willing to disallow non-valid UTF8 once we've seen a #!, it would make this code a lot nicer and handle the vast majority of use cases.

[oxr463]

PRoot, the original c implimentation, is Linux-only; it is written against Linux-specific libraries, etc. That being said, this rust version doesn't seem to be a direct translation of the other program. Therefore, I would try to rewrite the code to be as portable as possible.

Can you elaborate more on disallowing non-valid UTF-8? Are there examples for why we wouldn't want this?

[jyn514]

I'm not completely sure of this myself but I'll give it my best shot. On Linux (and I think most Unix platforms), paths can be arbitrary bytes, if you want an executable called /bin/\x253, you can have it. On Windows, paths are normally UTF-16, but can be arbitrary 16-bit integers (i.e. you can have invalid surrogate pairs in filenames). There's not a way to convert between the two, and you can't use the normal String class because it only allows valid UTF-8.

If we disallow that, then there will be paths we can't exec. However, in the vast majority of cases, this will be just a nuisance to code for because it's not in the standard library - see how getting and splitting the first line is about 10 lines of code where normally it would be BufReader.next_line().split. It's also the reason this commit introduces a new dependency on bstr.

All of this is only an issue for binary file paths, it's not that hard to check if the first two bytes of a file are #! even if the whole thing is a binary ELF file. Additionally, non-binary file paths will currently work on either Linux or Windows.

More info:

• https://docs.rs/bstr/0.1.1/bstr/#file-paths-and-os-strings
• path: Windows paths may contain non-utf8-representable sequences rust-lang/rust#12056
• https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation
• https://doc.rust-lang.org/book/ch08-02-strings.html#storing-utf-8-encoded-text-with-strings

[jyn514]

You mentioned this is a rewrite and should probably be portable - in that case we should get rid of the ASM in src/kernel/execve/loader

[oxr463]

You mentioned this is a rewrite and should probably be portable - in that case we should get rid of the ASM in src/kernel/execve/loader

I'm surprised that the loader was brought over from PRoot. I'm not sure how it should be re-implimented here, but I guess that can go into a separate issue.

[oxr463]

What about this, libpathrs?

[jyn514]

libpathrs looks like it addresses safe path handling. That could be useful as part of the main package for proot, but it's not directly related to parsing the path.

[oxr463]

Closing in favor of #14