"test" does not use access syscall for testing permissions

[jelly]

Unlike the GNU implementation of coreutils uutils doesn't use access which means ACL's are not taking into account or that root can write into a users home directory:

A simple reproducer:

root@ubuntu:~# ls -lh /home/admin/test.txt
-rw-r--r-- 1 admin admin 4 Jun 29 08:14 /home/admin/test.txt
root@ubuntu:~# test -w /home/admin/test.txt && echo 'write'
write
root@ubuntu:~# /usr/lib/cargo/bin/coreutils/test -w /home/admin/test.txt && echo "write"
root@ubuntu:~#
root@ubuntu:~# /usr/bin/gnutest -w /home/admin/test.txt  && echo "write"
write

This issue is reproducible on Ubuntu 26.04 with uutils 0.8.0. The Git main version does not use the access syscall so still suffers from the same issue.

[IRG-JUSTNOTORDINARY]

Still reproduces on Ubuntu 26.04.1 LTS (the August 2026 point release), rust-coreutils 0.8.0-0ubuntu3, where this is the default /usr/bin/test.

Two grant paths, in one reproducer — the second one (an ACL naming the user directly) isn't covered by the reproducer above, and may be useful when fixing:

sudo groupadd -f reprogrp
sudo useradd -M -N -g nogroup -G reprogrp reprouser
sudo mkdir -p /tmp/repro/viagroup /tmp/repro/viaacl && sudo chmod 755 /tmp/repro

# (a) access via a supplementary group only
sudo chown root:reprogrp /tmp/repro/viagroup && sudo chmod 070 /tmp/repro/viagroup

# (b) access via a POSIX ACL naming the user directly
sudo chown root:root /tmp/repro/viaacl && sudo chmod 700 /tmp/repro/viaacl
sudo setfacl -m u:reprouser:rwx /tmp/repro/viaacl

for d in viagroup viaacl; do
  printf '%-9s uutils=%s gnu=%s kernel=%s\n' "$d" \
    "$(sudo -u reprouser /usr/lib/cargo/bin/coreutils/test -x /tmp/repro/$d && echo true || echo false)" \
    "$(sudo -u reprouser /usr/bin/gnutest -x /tmp/repro/$d && echo true || echo false)" \
    "$(sudo -u reprouser python3 -c "import os,sys;sys.exit(0 if os.access('/tmp/repro/$d',os.X_OK) else 1)" && echo true || echo false)"
done

Actual:

viagroup  uutils=false gnu=true kernel=true
viaacl    uutils=false gnu=true kernel=true

A directory whose owning group is the caller's primary group is reported correctly, which lines up with the diagnosis in this issue: the answer is derived from the stat buffer rather than from access(2)/faccessat(2).

#9147 looks like the same root cause, reported as the supplementary-group symptom.

Context on impact, in case it helps with prioritisation: we hit this while setting up a small Samba file server whose entire access model is supplementary groups plus POSIX ACLs. Shell scripts that gate on [ -x "$dir" ] took the wrong branch, silently — the underlying operation would have succeeded. The shell built-in test in bash/dash is unaffected (it calls access(2) itself), so this only bites when /usr/bin/test is invoked as a binary, e.g. sudo -u someuser test -x ..., find -exec test, or from another language. That makes it easy to miss in testing and easy to hit in production.

[anastygnome]

I will fix this in my test PR, @sylvestre, @cakebaker , can you check ? #14966