Fix flaky usermod test - apparently even tests need AC these days

[ikerexxe]

The test_62_usermod_remove_supplementary_groups shell test was failing intermittently (apparently the heat is affecting this one too). Transformed it to Python framework for better reliability.

I have added two focused tests in test_usermod.py covering both normal and edge case scenarios. I have removed the original flaky shell test and runner script references.

[ikerexxe]

hmmm maybe the problem is not that exact test, but the last test in the list

[ikerexxe]

@hallyn I fear we'll need your help to investigate why the last test in tests/run_some always fails. When I opened this PR I thought the problem was with test_62_usermod_remove_supplementary_groups, but apparently that's not the case

[hallyn]

@ikerexxe

I see

serge@honeybadger:~/src/shadow$ grep "Status of" job-logs.txt  | grep FAI
2026-07-14T15:22:57.4258990Z # Status of test ./su/01/su_user.test: FAILURE
2026-07-14T15:22:57.4863241Z # Status of test ./libsubid/03_add_remove/add_remove_subids.test: FAILURE

[hallyn]

I can reproduce it on my laptop, though I don't yet get it.

I'll look into it.

[hallyn]

Bah. Looks like a change in id. It's returning

uid=424243(testsuite) gid=424243(424243) groups=424243(424243)^M

whereas in the past, if it couldn't find the group name, it would not give the (number) for gid and groups.

[hallyn]

So the following patch

ubuntu@shadow:~/shadow/tests$ git diff .
diff --git a/tests/su/01/config/etc/group b/tests/su/01/config/etc/group
index 245cc9cf..195a2358 100644
--- a/tests/su/01/config/etc/group
+++ b/tests/su/01/config/etc/group
@@ -40,3 +40,4 @@ nogroup:x:65534:
 crontab:x:101:
 Debian-exim:x:102:
 myuser:x:424242:
+testsuite:x:424243:
diff --git a/tests/su/01/run_su.exp b/tests/su/01/run_su.exp
index f1c1fb46..75463b95 100755
--- a/tests/su/01/run_su.exp
+++ b/tests/su/01/run_su.exp
@@ -30,7 +30,8 @@ expect {
                puts "\ntimeout...FAIL"
                exit 1
        }
-       "uid=424243(testsuite) gid=424243 groups=424243"
+       "uid=424243(testsuite) gid=424243(testsuite) groups=424243(testsuite)"
+
 }

 expect "$ "                    ;# Wait for the prompt

Fixes the first failure.

[hallyn]

The second test failure seems to be pointing to a real bug in SUB_UID_MIN handling.

[alejandro-colomar]

The second test failure seems to be pointing to a real bug in SUB_UID_MIN handling.

Hummm, would you be able to bisect it?

Bah. Looks like a change in id. It's returning

uid=424243(testsuite) gid=424243(424243) groups=424243(424243)^M

whereas in the past, if it couldn't find the group name, it would not give the (number) for gid and groups.

Where/when was this changed? It'd be interesting to note it in the commit message.

[hallyn]

It worked as of d7164fc, so this should be bisectable.

[hallyn]

ubuntu@shadow:~/shadow$ git bisect good
b31ba8af5d4a351282605e85687dbdc90cdec264 is the first bad commit
commit b31ba8af5d4a351282605e85687dbdc90cdec264
Author: Hadi Chokr <hadichokr@icloud.com>
Date:   Mon Jul 6 14:29:13 2026 +0200

    subids: fix security regression which can cause overlapping ranges

(I'm keeping the running log because about to be out of battery)

[hallyn]

Bah. Looks like a change in id. It's returning

uid=424243(testsuite) gid=424243(424243) groups=424243(424243)^M

whereas in the past, if it couldn't find the group name, it would not give the (number) for gid and groups.

Where/when was this changed? It'd be interesting to note it in the commit message.

Not sure, but i can verify that in ubuntu 22.04 it does not show that, while
in 26.04 it does. That's the rust based uutils version.

[hallyn]

Anyway the simplest thing for that is to just add a group name in the config/etc/group file for the test.

[hallyn]

I notice that useradd from master branch does not create a subuid entry for new users. useradd from 26.04 ubuntu version correctly does. It does look at /etc/login.defs, presumably looking for SUB_UID_MIN. I suspect this is related. Also, we should probably have a regression test for subuid creation (both to make sure it gets created hwen it should and that it doesn't when it shouldn't).

[hallyn]

So, not related. src/useradd.c

2574 #ifdef ENABLE_SUBIDS
2575 subuid_count = getdef_ulong ("SUB_UID_COUNT", 65536);
2576 subgid_count = getdef_ulong ("SUB_GID_COUNT", 65536);
2577 is_sub_uid = should_assign_subuid();
2578 is_sub_gid = should_assign_subgid();
2579 #endif /* ENABLE_SUBIDS */

should_assign_subuid() uses user_id, but thta doesn't get assigned until line 2639.

[hallyn]

@ikerexxe I've pushed two patches to your branch. So if you're making more changes , please pull before.

[alejandro-colomar]

Thanks!