path_symlink panics when old_path is relative

[Yesterday17]

Assume we're calling path_symlink("testing", 1234, "/test-target").

wasmer/lib/wasi/src/syscalls/mod.rs

Lines 2826 to 2829 in 03e8911

	let (source_inode, _) =
	wasi_try!(state
	.fs
	.get_parent_inode_at_path(inodes.deref_mut(), fd, old_path_path, true));

source_inode is got from get_parent_inode_at_path:

wasmer/lib/wasi/src/state/mod.rs

Lines 1274 to 1294 in 5db56ce

	pub(crate) fn get_parent_inode_at_path(
	&self,
	inodes: &mut WasiInodes,
	base: WasiFd,
	path: &Path,
	follow_symlinks: bool,
	) -> Result<(Inode, String), Errno> {
	let mut parent_dir = std::path::PathBuf::new();
	let mut components = path.components().rev();
	let new_entity_name = components
	.next()
	.ok_or(Errno::Inval)?
	.as_os_str()
	.to_string_lossy()
	.to_string();
	for comp in components.rev() {
	parent_dir.push(comp);
	}
	self.get_inode_at_path(inodes, base, &parent_dir.to_string_lossy(), follow_symlinks)
	.map(|v| (v, new_entity_name))
	}

Here path is testing, so we got components = Components([Normal("testing")]), So:

• new_entity_name = testing
• parent_dir = ""

Since parent_dir is empty, get_inode_at_path returns base directly.

wasmer/lib/wasi/src/syscalls/mod.rs

Lines 2830 to 2833 in 03e8911

	let depth = wasi_try!(state
	.fs
	.path_depth_from_fd(inodes.deref(), fd, source_inode))
	- 1;

So source_inode and fd here are actually referring the same thing. path_depth_from_fd return 0. The minus opration causes overflow.

wasmer/lib/wasi/src/syscalls/mod.rs

Lines 2861 to 2865 in 03e8911

	let mut source_path = std::path::Path::new(&old_path_str);
	let mut relative_path = std::path::PathBuf::new();
	for _ in 0..depth {
	relative_path.push("..");
	}

The overflow would not be panic in release build, but results in another panic where the push operation exceeds capacity of relative_path with depth = 2**32 - 1.

Also, I found the use of Path and str very confusing. Maybe it needs to be unified?

[syrusakbary]

Note: this issue seems related to #3228

[syrusakbary]

Note: this issue seems related to #3228