regexes are not supported

[computezrmle]

Please ensure sudo-rs does not violate the regular expressions standard published here:
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap09.html

A volunteer running tasks for CERN's public project https://lhcathome.cern.ch/lhcathome/index.php recently reported his CERN tasks were failing after he upgraded his Linux box to Ubuntu 25.10.
He could track this down to sudo-rs which complains about a custom sudoers file using regular expressions like this:
Cmnd_Alias LHCATHOMEBOINC_11 = /usr/bin/systemctl ^(freeze|thaw) ATLAS_[-a-zA-Z0-9_]+\.scope$

The volunteer found out that after replacing \. with . sudo-rs accepts the sudoers file.

According to the regular expressions standard above (especially chapters 9.3.3, 9.3.4) a dot is a placeholder for nearly 'all characters' while an escaped dot stands for a literal dot.
The latter is the expected meaning in the custom sudoers file.

[bjorn3]

sudo-rs supports neither wildcards nor regexes. Wildcards (like /usr/bin/ls *.txt) are a huge footgun as they match spaces too and thus allow multiple arguments when only one was intended. Regexes probably have the same footgun when using .*, but unlike wildcards it is possible to use them correctly. I will discuss with the rest of the team if we want to support them, but if not we should at the very least parse the ^...$ as a regex and reject it rather than interpreting it as verbatim ^ and $ characters.

[computezrmle]

... we should at the very least parse the ^...$ as a regex and reject it ...

This would mean a show stopper for the CERN usecase.

[squell]

Regular expressions were also only added to ogsudo quite recently (close to the sudo-rs project start); and so the sudo we used as a compliance target (the one actually shipped in stable distro's at the time) did not support regexes either. That was the main evolutionary reason for not picking them up initially. Main reason to not pick them up since have been

• Regex support is not in the Rust std library; that means we have to add dependencies (maybe the dependency tree for regexes isn't that bad nowadays, but we also see this in the light that it's only for a feature many people probably don't or shouldn't use), or we have to go through libc. I'm not too worried about CVE's that glibc has had in this area; I think the most recent one was in 2019 and that required the attacker to control the regular expression (which is not an attack vector for us)

• Apparent limited use (this is the first time we learned it is being used)

• We were wondering whether it really "solves" anything; the original non-regex-wildcards-as-arguments in the sudoers file are indeed frightening (to us), but the ogsudo blog post https://www.sudo.ws/posts/2022/03/sudo-1.9.10-using-regular-expressions-in-the-sudoers-file/ itself also notes:

  Like many other sysadmins, I do not like regular expressions. It is easy to write difficult to debug expressions, which you may not understand later (or even the next day).

  Personally I've also solved quite a bit of stuff using regular expressions, but indeed I've always considered that as "hacky fun" which is write-only. Which is not an ideal property for something that lives inside a security policy configuration file (which is what /etc/sudoers is).

• There is a workaround in the form of "trampoline scripts". For example:

In the case of

Cmnd_Alias LHCATHOMEBOINC_11 = /usr/bin/systemctl ^(freeze|thaw) ATLAS_[-a-zA-Z0-9_]+\.scope$

This also suggests a shell script atlasctl:

#! /bin/sh

case "$1" in
    freeze)
        echo /usr/bin/systemctl freeze "ATLAS_$2.scope";;
    thaw)
        echo /usr/bin/systemctl thaw "ATLAS_$2.scope";;
    *)
        echo "usage: atlas (freeze|thaw) ID"
        exit 1;;
esac

And then give a user permission to run that:

Cmnd_Alias LHCATHOMEBOINC_11 = /usr/local/bin/atlasctl

Advantages:

• A script can in do even more checking of the arguments than is possible with a regex; and it can be safely tested. One misplaced space ( ) in the original LHCATHOMEBOINC_11regex could already cause trouble, that is not the case here.
• It's more userfriendly, since it's an actual small program rather than having the user interface be "you have to type in the magic words to systemctl"

In general, for really fine-grained control, the "trampoline script" approach will always be "the best" (whether or not we support regular expressions). Then the main question remaining is, are there use cases where writing a full script is clearly ridiculous, but some flexibility in arguments fed to a program would be a good thing.

[squell]

Note: Todd Miller has also recommended the "wrapper" script approach.