A wildcard in the arguments of a sudoers rule matches across spaces, so a rule meant for one log file can also allow a second, unrelated file on the same command line. The safer pattern is an anchored regular expression for the arguments, or a small wrapper script that checks input itself.
How sudo matches arguments
The sudoers manual page says command line arguments are matched as a single, concatenated string. A wildcard such as * or ? therefore matches across word boundaries. In file names a slash is not matched by a wildcard, but in arguments it is, because arguments can hold any text.
That detail is easy to miss when you write a rule that looks tight.
The classic example
The manual uses this rule for an operator group:
%operator ALL = /bin/cat /var/log/messages*
It allows sudo cat /var/log/messages.1, which is the intent. It also allows this:
sudo cat /var/log/messages /etc/shadow
The second path rides along after a space, and the * happily swallows it. The user just read a file you never meant to share.
The fix from the manual
The same page suggests a regular expression for the arguments:
%operator ALL = /bin/cat ^/var/log/messages[^[:space:]]*$
This matches a single file whose name starts with /var/log/messages and contains no white space. The anchors at both ends matter. Without ^ and $ you reopen the gap.
The manual also adds a note worth keeping: for anything non-trivial, do the argument handling outside sudoers, in a script. Then the rule grants one fixed path and the script decides what is acceptable.
Rules that stay safe
- Prefer exact commands with fixed arguments over globs.
- If you need a pattern, anchor it and exclude white space.
- Grant a script you own, kept in a root owned directory that no one else can write, rather than a general tool like
cat,tarorfind. - Remember that regular expressions in the command name (not the arguments) bring their own limits. The manual says negating such commands is not reliable and that sudo must run the path the user typed, which can open a time of check versus time of use gap.
Test before you rely on it
Edit sudoers with visudo so a typo does not lock you out. Then test as the target user with sudo -l to list what is allowed, and try the bad input on purpose. Run the rule with an extra path and confirm it is refused. A rule you have only tested with the happy case is not tested.
If you keep rules in files under sudoers.d, give each a clear name and review them like code. Related reading: least privilege for AI coding agents uses the same idea of narrow grants.
Quick check
Does /bin/cat /var/log/messages* only allow files starting with that name?
No. Arguments are matched as one string and the wildcard can match spaces, so extra paths after the first one can also match.
What is the safer rule?
An anchored regular expression such as ^/var/log/messages[^[:space:]]*$, or a wrapper script that validates its input.
Sudo rules are something your team reviews by hand. If you also want hosts and dependencies inventoried in one place, Safeguard offers asset discovery and SBOM and dependency scanning, and there is a free scan at gold.safeguard.sh/scan.
Sources
- sudoers(5) manual page, man7.org, sections on wildcards, "Wildcards in command arguments" and "Regular expressions in command names"
Last reviewed: 19 October 2026.
