Execute command in ESXi (RUST)

[deadlock]

Hello XSS,

I'm currently working on a Rust application for ESXi and need to execute commands on the host system.

For this, I'm using std::process::Command, but it doesn't seem to be working as expected. Here’s the code I’m using:

use std::process::Command;

fn main() {
    let output = Command::new(“ls”).output().unwrap();

    if output.status.success() {
        let stdout = String::from_utf8_lossy(&output.stdout);
        println!(“{}”, stdout);
    } else {
        let stderr = String::from_utf8_lossy(&output.stderr);
        eprintln!(“Error: {}”, stderr);
    }
}

When I run this on ESXi, it panics and outputs the following error:

thread 'main' panicked at std/src/sys_common/process.rs:153:17:
called `Result::unwrap()` on an `Err` value: Os { code: 25, kind: Uncategorized, message: “Not a tty” }

I am compiling the application with the following command:

cargo build --target x86_64-unknown-linux-musl --release

It seems that ESXi doesn’t support SOCK_SEQPACKET, which might be related to this issue.

I found a related GitHub issue where the solution involved modifying the Rust standard library to avoid using SOCK_SEQPACKET. However, I encountered problems when trying to compile the standard library for x86_64-unknown-linux-musl, and I believe there might be simpler and more appropriate ways to solve this.

Has anyone encountered a similar problem, or does anyone have suggestions on how I can execute commands on the ESXi host without running into this issue? Any help would be greatly appreciated.

 

[m43stro]

Did you find a solution?

 

[reqwest]

x86_64-unknown-linux-musl

Не рекомендую использовать MUSL под ESXi - лучше использовать cargo zigbuild с нужной версией GLIBC.

It seems that ESXi doesn’t support SOCK_SEQPACKET, which might be related to this issue.

Можешь использовать более старую версию раста (>1.73) или пропатчить std и пересобрать из исходников.
Issue с аналогичной проблемой и патчем: std::process::Command is broken on VMWare ESXi

 

[shrekushka]

Issue с аналогичной проблемой и патчем: std::process::Command is broken on VMWare ESXi

And they say ESXi is "like-Linux"...

 

[shrekushka]

nobody0, apparently ESXi does support SOCK_SEQPACKET, it just helpfully remaps it to EINVAL & calls that “linuxcompatible"

 

[monar]

Use exec crate instead of std::process or use nix crate for direct system calls or use libc directly

 

[shrekushka]

Use exec crate instead of std::process or use nix crate for direct system calls or use libc directly

ismell_llm: buzzwords w/o solving the kernel capability gap

 

[monar]

1. exec crate - Uses fork() + execve() directly, bypassing the
problematic socketpair(AF_UNIX, SOCK_SEQPACKET, 0, ...) call
2. nix crate - Direct syscall access without std library abstractions
3. libc::system() - Uses /bin/sh directly, which ESXi supports

ismell_llm: buzzwords w/o solving the kernel capability gap

 

[shrekushka]

1. exec crate - Uses fork() + execve() directly, bypassing the
problematic socketpair(AF_UNIX, SOCK_SEQPACKET, 0, ...) call
2. nix crate - Direct syscall access without std library abstractions
3. libc::system() - Uses /bin/sh directly, which ESXi supports

Are you an actual practitioner who's like actually tested it on ESXi? or a quick LLM patch up?
Everything's surface level.

PS. Throw in a reproducible paste: Cargo.toml + main.rs (whichever technique) + strace-f out, otherwise it’s just buzzword vapor.

 

[monar]

Are you an actual practitioner who's like actually tested it on ESXi? or a quick LLM patch up?
Everything's surface level.

PS. Throw in a reproducible paste: Cargo.toml + main.rs (whichever technique) + strace-f out, otherwise it’s just buzzword vapor.

Reproducible paste? Brother, this is xss, not your personal code-writing service, the solutions work for anyone who actually understands posix syscalls. Maybe start with a Linux tutorial before jumping to esxi?

 

[shrekushka]

Reproducible paste? Brother, this is xss, not your personal code-writing service, the solutions work for anyone who actually understands posix syscalls. Maybe start with a Linux tutorial before jumping to esxi?

I've sparred with plenty of folk here on the forum, at least they've like made genuine attempts to technically engage/defend/refute instead of GPT-3.5's cringey punchlines + language style.
PS. The account's burned, see you next week with a newly registered alt.

 

[monar]

I've sparred with plenty of folk here on the forum, at least they've like made genuine attempts to technically engage/defend/refute instead of GPT-3.5's cringey punchlines + language style.
PS. The account's burned, see you next week with a newly registered alt.

что ты пишешь вообще, тебе по факту сказали все, а ты мне дизы лепишь и говоришь что у меня аккаунт умер, повзрослей уже!
(а еще вопрос, ты когда регу аккаунта видишь меньше своей, у тебя твое пубертатное очко сгорает что ли?)

 

[shrekushka]

что ты пишешь вообще, тебе по факту сказали все, а ты мне дизы лепишь и говоришь что у меня аккаунт умер, повзрослей уже!
(а еще вопрос, ты когда регу аккаунта видишь меньше своей, у тебя твое пубертатное очко сгорает что ли?)

"told everything" != surface level answers with no accountability, makes it feel like AI slop.

 

[Quake3]

or does anyone have suggestions on how I can execute commands on the ESXi host without running into this issue

В esxi какая-то другая оболочка, не bash, а sh или что, не силен в линуксах; на Си использовал как-то так:

char *buf = malloc()
...
strcpy(buf, "ls");
strcat(buf, " 2>&1");
FILE* fp = popen(buf, "r");
fread..

 

[shrekushka]

В esxi какая-то другая оболочка, не bash

BusyBox ash