In a Visual Studio Code devcontainer based on Debian Bullseye the test user::test::groups fails. <details><summary>Backtrace</summary> ``` $ RUST_BACKTRACE=1 cargo test -p fs-mistrust --lib Finished test [unoptimized + debuginfo] target(s) in 0.09s Running unittests (target/debug/deps/fs_mistrust-bf6b7cb33876b3a0) running 26 tests test err::test::bits ... ok test test::default_mistrust ... ok test user::test::lookup_id ... ok test test::admin_only ... ok test user::test::username_from_env ... ok test user::test::selfnamed ... ok test user::test::username_ignoring_env ... ok test user::test::username_real ... ok test test::multiple_errors ... ok test test::check_contents ... ok test test::trust_everyone ... ok test test::want_type ... ok test test::readable_ok ... ok test dir::test::bad_paths ... ok test dir::test::read_and_write ... ok test test::trust_gid ... ok test walk::test::past_root ... ok test test::sticky ... ok test dir::test::easy_case ... ok test walk::test::simple_path ... ok test walk::test::unix_permissions ... ok test test::simple_cases ... ok test test::make_directory ... ok test walk::test::repeats ... ok test walk::test::looping ... ok test user::test::groups ... FAILED failures: ---- user::test::groups stdout ---- thread 'user::test::groups' panicked at 'assertion failed: groups.contains(&cur_gid)', crates/fs-mistrust/src/user.rs:264:9 stack backtrace: 0: rust_begin_unwind at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:584:5 1: core::panicking::panic_fmt at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panicking.rs:143:14 2: core::panicking::panic at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panicking.rs:48:5 3: fs_mistrust::user::test::groups at ./src/user.rs:264:9 4: fs_mistrust::user::test::groups::{{closure}} at ./src/user.rs:256:5 5: core::ops::function::FnOnce::call_once at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/ops/function.rs:227:5 6: core::ops::function::FnOnce::call_once at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/ops/function.rs:227:5 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. failures: user::test::groups test result: FAILED. 25 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.03s ``` </details> This appears to be due to `cur_groups` being `vec![999]` but `cur_gid` being `1000` and the test assumes that `cur_gid` will be in `cur_groups`. I'm not entirely sure why the container is set up this way, but it seems like it might be permitted by specification. > It is unspecified whether the effective group ID of the calling > process is included in the returned list. (Thus, an application > should also call getegid(2) and add or remove the resulting > value.) From https://man7.org/linux/man-pages/man2/getgroups.2.html Here are some command outputs that seem relevant. ``` vscode ➜ /workspaces/arti (devcontainer) $ grep vscode /etc/group /etc/passwd /etc/group:vscode:x:1000: /etc/group:rustlang:x:999:vscode /etc/passwd:vscode:x:1000:1000::/home/vscode:/bin/bash vscode ➜ /workspaces/arti (devcontainer) $ ps -q $$ -eo pid,user,args,group,rgroup,supgrp PID USER COMMAND GROUP RGROUP SUPGRP 252 vscode /bin/bash vscode vscode rustlang vscode ➜ /workspaces/arti (devcontainer) $ id uid=1000(vscode) gid=1000(vscode) groups=1000(vscode),999(rustlang) ```