"test" does not use access syscall for testing permissions #13197

Activity

1. cakebaker

   added

   U - test

   on Jun 29, 2026
2. jelly

   changed the title [-]test does not use access syscall for testing permissions[/-] [+]"test" does not use access syscall for testing permissions[/+] on Jun 29, 2026
3. jelly

   added a commit that references this issue on Jun 30, 2026

   Use `fsinfo` for checking write access

   ...

   aaacaa1
4. IRG-JUSTNOTORDINARY commented on Sep 6, 2026

   

   IRG-JUSTNOTORDINARY

   on Sep 6, 2026

   More actions

   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.
5. anastygnome commented on Oct 1, 2026

   

   anastygnome

   on Oct 1, 2026

   Last edited by anastygnome

   Contributor

   More actions

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

   closed this as completedin #14966on Oct 3, 2026