-
Notifications
You must be signed in to change notification settings - Fork 164
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
Panic in recvmsg msghdr decoding / read_sockaddr_os() with abstract unix socket address #660
Comments
psychon
changed the title
Bug in recvmsg msghdr decoding?
Panic in recvmsg msghdr decoding / read_sockaddr_os() with abstract unix socket address
May 6, 2023
I had another idea:
Decoding this via the Rust playground confirms that fn main() {
let sun_path = [0, 47, 116, 109, 112, 47, 46, 88, 49, 49, 45, 117, 110, 105, 120, 47, 88, 48, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0,
0, 0, 0, 0, 0, 0, 80, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 160, 235, 91, 85, 85, 85, 0, 0, 80, 0, 0, 0, 0, 0, 0, 0, 160, 235, 91, 85, 85, 85, 0, 0, 80, 0, 0, 0, 0, 0, 0, 0,
160, 235, 91, 85, 3, 0, 0, 0, 3, 0, 0, 0, 3, 0, 0, 0, 219, 238, 85, 85, 85, 85];
let relevant_part = &sun_path[1..18];
println!("{:?}", std::str::from_utf8(relevant_part));
}
|
Ah, I re-read the man page. Unix sockets bound to a path contain a null terminated string and the length of the sockaddr includes the zero byte:
Abstract sockets instead do not include the zero byte:
|
psychon
added a commit
to psychon/rustix
that referenced
this issue
May 6, 2023
This commit duplicates the existing test_unix_msg() tests. The duplicated version uses an abstract unix socket instead of a path based one. To make the code-duplication not too bad, a helper function do_test_unix_msg() is introduced that does "the actual work" and just needs as input a socket address. This new test currently fails. This reproduces bytecodealliance#660. Signed-off-by: Uli Schlachter <[email protected]>
psychon
added a commit
to psychon/rustix
that referenced
this issue
May 6, 2023
This case was just not implemented at all. Abstract unix sockets are not null-terminated and are indicated by sun_path beginning with a null byte. Fixes: bytecodealliance#660 Signed-off-by: Uli Schlachter <[email protected]>
psychon
added a commit
to psychon/rustix
that referenced
this issue
May 6, 2023
The previous commit for this only fixed the linux_raw backend. This commit applies the same fix to the libc backend. Fixes: bytecodealliance#660 Signed-off-by: Uli Schlachter <[email protected]>
cgwalters
pushed a commit
to cgwalters/rustix
that referenced
this issue
May 23, 2023
* test_unix_msg: Remove thread synchronisation This refactors the test_unix_msg() test a bit. No change in behaviour is intended. Previously, two threads were started in parallel. The server thread used a mutex and a condition variable to indicate that it set up its listening socket. The client thread waited for this signal before it attempted to connect. This commit makes the code instead bind the server socket before starting the worker threads. That way, no synchronisation is necessary. Signed-off-by: Uli Schlachter <[email protected]> * Add test for abstract unix sockets This commit duplicates the existing test_unix_msg() tests. The duplicated version uses an abstract unix socket instead of a path based one. To make the code-duplication not too bad, a helper function do_test_unix_msg() is introduced that does "the actual work" and just needs as input a socket address. This new test currently fails. This reproduces bytecodealliance#660. Signed-off-by: Uli Schlachter <[email protected]> * Fix recvmsg() on abstract unix sockets This case was just not implemented at all. Abstract unix sockets are not null-terminated and are indicated by sun_path beginning with a null byte. Fixes: bytecodealliance#660 Signed-off-by: Uli Schlachter <[email protected]> * Strengthen recvmsg() test The fix in the previous commit added some parsing for abstract unix sockets. I wasn't sure whether I got all the indicies right, so this commit extends the existing test to check that the result from recvmsg() contains the expected socket address. Signed-off-by: Uli Schlachter <[email protected]> * Fix recvmsg() on abstract unix sockets on libc backend The previous commit for this only fixed the linux_raw backend. This commit applies the same fix to the libc backend. Fixes: bytecodealliance#660 Signed-off-by: Uli Schlachter <[email protected]> * Restrict test_abstract_unix_msg() test to Linux Abstract unix sockets are a feature of the Linux kernel that is not available elsewhere. Signed-off-by: Uli Schlachter <[email protected]> * Skip the test extension on FreeBSD Commit "Strengthen recvmsg() test" added a new assertion to this test. For unknown reasons, this test failed in Currus CI on x86_64-unknown-freebsd-13 as follows: ---- unix::test_unix_msg stdout ---- thread 'client' panicked at 'assertion failed: `(left == right)` left: `Some("/tmp/.tmpy5Fj4e/scp_4804")`, right: `Some("(unnamed)")`', tests/net/unix.rs:243:13 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'unix::test_unix_msg' panicked at 'called `Result::unwrap()` on an `Err` value: Any { .. }', tests/net/unix.rs:276:19 The text "(unnamed)" comes from the Debug impl of SocketAddrUnix. This text is generated when SocketAddrUnix::path() returns None. I do not know why this happens. I am just trying to get CI not to complain. A random guess would be that recvmsg() does not return the endpoint for connected sockets. This is because the "recvmsg" man page for FreeBSD says: > Here msg_name and msg_namelen specify the source address if the socket > is unconnected; Signed-off-by: Uli Schlachter <[email protected]> --------- Signed-off-by: Uli Schlachter <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
@notgull added support for
recvmsg
in #505 and then wanted to use that code in x11rb: psychon/x11rb#815 However, thererustix
panics in one of the existing examples.I tried to port this into a self-contained example. This requires something (e.g. an X11 server) to listen on the abstract unix socket at
/tmp/.X11-unix/X0
.Cargo.toml and main.rs
Running the above program locally produces for me:
Running this under
strace
says that the socket name is correct:The number
48
is ASCII for0
, so this seems to be some kind of off-by-one?I am not sure whether the kernel even zero-terminates abstract sockets.
man 7 unix
says:The text was updated successfully, but these errors were encountered: