v4.2.0 - bufixes, edge cases, and chsr consistency

.cargo/config.toml

@@ -48,6 +48,10 @@ RAR_CHSR_EDITOR_PATH = "/usr/bin/vim"
 RAR_TIMEOUT_TYPE = "ppid"
 RAR_TIMEOUT_DURATION = "00:05:00"
 RAR_TIMEOUT_MAX_USAGE = ""
+RAR_PASSWORD_TRIES = "3"
+RAR_PASSWORD_DELAY = "00:00:05"
+# Who owns the terminal of a command run as another user: caller, or target like sudo.
+RAR_TTY_OWNER = "caller"
 RAR_PATH_DEFAULT = "delete"
 RAR_PATH_ADD_LIST = "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
 RAR_PATH_REMOVE_LIST = ""

.github/workflows/build.yml

@@ -28,8 +28,12 @@ jobs:
         session [success=1 default=ignore]  pam_permit.so
         session requisite                   pam_permit.so
         session required                    pam_permit.so" | tee /etc/pam.d/dosr'
+    - name: Install Dependencies
+      run: |
+        sudo apt-get update
+        sudo apt-get install -y clang pkg-config libpam0g-dev libseccomp-dev pandoc
     - name: Install RootAsRole
-      run: cargo xtask install -bip sudo
+      run: cargo xtask install -bp sudo
     - name: print config
       run: dosr cat /etc/security/rootasrole.json
     - name: getenv

.github/workflows/install-tests.yml

@@ -20,7 +20,7 @@ jobs:
       - name: Install git and build dependencies
         run: |
           apt update -y
-          apt install -y git curl build-essential pkg-config libpam0g-dev
+          apt install -y git curl build-essential clang pkg-config libpam0g-dev libseccomp-dev pandoc
           apt install -y sudo ca-certificates
 
       - name: Checkout code
@@ -47,7 +47,7 @@ jobs:
 
       - name: Install RootAsRole
         run: |
-          cargo xtask install --debug -bip sudo
+          cargo xtask install --debug -bp sudo
 
       - name: Verify installation
         run: |
@@ -71,8 +71,7 @@ jobs:
           dnf config-manager --set-enabled crb || true
           dnf install -y epel-release || true
           dnf makecache -y
-          dnf install -y pandoc || true
-          dnf install -y git gcc pkg-config pam-devel
+          dnf install -y git clang pkg-config pam-devel libseccomp-devel pandoc
           dnf install -y sudo ca-certificates
 
       - name: Checkout code
@@ -99,7 +98,7 @@ jobs:
 
       - name: Install RootAsRole
         run: |
-          cargo xtask install -bip sudo
+          cargo xtask install -bp sudo
 
       - name: Verify installation
         run: |
@@ -126,7 +125,7 @@ jobs:
       - name: Install git and build dependencies
         run: |
           zypper refresh
-          zypper install -y bash rustup git curl gcc pkg-config pam-devel
+          zypper install -y bash rustup git curl clang pkg-config pam-devel libseccomp-devel pandoc
           zypper install -y sudo
           rustup toolchain install stable
           rustup update
@@ -152,7 +151,7 @@ jobs:
 
       - name: Install RootAsRole
         run: |
-          cargo xtask install -bip sudo
+          cargo xtask install -bp sudo
 
       - name: Verify installation
         run: |

.github/workflows/quality.yml

@@ -40,8 +40,10 @@ jobs:
           components: clippy
           override: false
 
-      - name: Install RootAsRole
-        run: cargo xtask dependencies -dip sudo
+      - name: Install Dependencies
+        run: |
+          sudo apt-get update
+          sudo apt-get install -y pkg-config libpam0g-dev libseccomp-dev pandoc
 
       # if pull request review only
       - uses: mbrobbel/rustfmt-check@master

.github/workflows/tests.yml

@@ -39,7 +39,7 @@ jobs:
         session required                    pam_permit.so" | tee /etc/pam.d/dosr'
 
     - name: Install Dependencies
-      run: cargo xtask dependencies -dip sudo
+      run: apt install -y pkg-config libpam0g-dev libseccomp-dev pandoc
 
     - name: run integration coverage
       run: cargo +nightly coverage

.gitignore

@@ -61,9 +61,10 @@ obj/
 bin/
 
 # Hidden folders (for Linux IDE)
-/.idea/
 *target/
-*/src/xml_version.rs
+/.*/
+!/.cargo/
+!/.github/
 
 # Rust crates
 */Cargo.lock

Cargo.toml

@@ -5,7 +5,7 @@ exclude = ["fuzz", "book", "sudoers-reader"]
 [workspace.package]
 edition = "2024"
 rust-version = "1.93.0"
-version = "4.1.0"
+version = "4.2.0"
 license = "LGPL-3.0-or-later"
 homepage = "https://lechatp.github.io/RootAsRole/"
 repository = "https://github.com/LeChatP/RootAsRole"
@@ -97,8 +97,8 @@ undocumented_unsafe_blocks = { level = "warn", priority = 2 }
 allow-unwrap-in-tests = true
 
 [workspace.dependencies]
-rootasrole-core = { version = "4.1.0", path = "core" }
-rootasrole-exec = { version = "4.1.0", path = "exec" }
+rootasrole-core = { version = "4.2.0", path = "core" }
+rootasrole-exec = { version = "4.2.0", path = "exec" }
 
 [dependencies]
 rootasrole-core = { workspace = true }

book/src/background/performance.md

@@ -4,21 +4,34 @@ Infrastructure-as-code environments can generate large and complex privilege pol
 
 With RaR policies, every role and task can introduce additional access control rules. In large infrastructures, this can result in thousands of policy entries being evaluated during production operations. Therefore, the privilege evaluation engine must scale efficiently.
 
-The initial implementation of dosr revealed a scalability challenge. The first JSON-based policy engine was faster than sudo for small policies, but its execution time increased significantly as the number of tasks grew.
+> Update for 4.2.0 of the performance evaluation is co-written with Claude for correctness.
 
-![Performance degradation of the initial JSON-based dosr implementation as policy size increases from 1 to 100 tasks.](https://github.com/LeChatP/RaR-perf/raw/main/before_json_result.png)
+## How it is measured
+
+The measures are performed with the dedicated [RaR-perf](https://github.com/LeChatP/RaR-perf) repository. Each tool runs `/usr/bin/true` as root, without a password, with a policy of N rules where only the last rule allows the command. [hyperfine](https://github.com/sharkdp/hyperfine) measures the time of each run. Since a remark from reddit, 4.2.0 evaluations verifies the `/usr/bin/true` performance too for completeness.
+
+The tools do not do the same work for the same rule: sudo and dosr (since 4.0) run the PAM account and session stacks, even when they ask no password, while doas and `please` do not call PAM when they ask no password. A comparison shows how much each design costs.
+
+After some thoughts, run0 is not in the figures. Its rules aren't read at each run: polkitd loads them once, and keep it loaded in memory, while the other tools read their policy each time. Its numbers would not measure the same work. That said, the time to make a dbus call is significantly slower than reading a policy of 10000 tasks.
+Another point is : polkit's run0 rules has no idea about what command is being executed as input. So that makes the comparison not even feasible.
+
+## The first implementation
+
+The initial implementation of the policy engine revealed a scalability challenge. It was measured in April 2025, while 3.1.0 was in development, when dosr was still named `sr`. The first JSON-based policy engine was faster than sudo for small policies, but its execution time increased significantly as the number of tasks grew.
+
+![Performance degradation of the initial JSON-based policy engine (sr, 3.1.0 in development) as policy size increases from 1 to 90 tasks.](https://github.com/LeChatP/RaR-perf/raw/main/figures/25-04-16_sudo-sr-json/result.png)
 
 As shown above, the initial implementation suffered from poor scalability. While it performed well with small policies, the execution time quickly surpassed sudo as policy size increased, making it unsuitable for large-scale deployments.
 
-## Moving from JSON to CBOR
+### Moving from JSON to CBOR
 
 The first optimization focused on the policy storage format. JSON is human-readable and convenient, but parsing large JSON documents introduces unnecessary overhead. To reduce this cost, dosr introduced support for Compact Binary Object Representation (CBOR), a binary format designed for efficient serialization and parsing, and completely compatible with the JSON structure.
 
-![Limited performance gain after switching to CBOR, showing the underlying scalability issue persists as policy size increases to 400 tasks.](https://github.com/LeChatP/RaR-perf/raw/main/before_cbor_result.png)
+![Limited performance gain after switching to CBOR, showing the underlying scalability issue persists as policy size increases to 400 tasks (time in seconds).](https://github.com/LeChatP/RaR-perf/raw/main/figures/25-04-16_sudo-sr-cbor/result.png)
 
 Although CBOR reduced part of the parsing overhead, the improvement remained limited. The performance curve continued to increase significantly with policy size, demonstrating that file parsing was only one part of the problem. The main bottleneck was located deeper in the policy evaluation architecture.
 
-## Architectural Optimisation
+### Architectural Optimisation
 
 The next optimization phase focused on the complete execution path of dosr. Instead of only improving the policy format, the internal architecture was redesigned to remove unnecessary overhead.
 
@@ -31,21 +44,64 @@ The main improvements included:
 
 These changes, combined with the CBOR policy format, resulted in a significant improvement in both execution time and scalability.
 
-![Final scalability comparison showing the fully optimized dosr (with CBOR and architectural improvements) vastly outperforming sudo at scale, benchmarked up to 10,000 tasks.](https://github.com/LeChatP/RaR-perf/raw/main/result_25-07-04_15.44.png)
+![Scalability of the optimized engine (sr, 3.1.0 in development, with CBOR and architectural improvements) and of sudo, benchmarked up to 10,000 tasks in July 2025.](https://github.com/LeChatP/RaR-perf/raw/main/figures/25-07-04_sudo-sr/result.png)
 
-The optimized dosr engine now outperforms sudo by up to 77% for a single-rule policy. More importantly, its execution time scales linearly and grows approximately 40% slower than sudo, maintaining a performance advantage even with policies containing tens of thousands of tasks.
+In July 2025, just before the release of 3.1.0, this engine ran 77% faster than sudo for a single-rule policy, and its execution time grew approximately 40% slower than sudo's as the policy grew.
 
 <blockquote class="caroot">
 Do you see these very straight lines compared to the previous ones? This is because we changed the way to way to plot the data. Instead of using a some arbitrary increase (e.g., 100, 200, 300), we used a logarithmic increase.
 </blockquote>
 
+## From 3.1.0 to 4.1.0
+
+These numbers were not measured again for the releases that followed. In October 2026, every version was built again and measured on the same virtual machine, with the same policy:
+
+| version | one rule | each additional rule |
+|---|---|---|
+| 3.1.0 | 5.4 ms | 1.9 µs |
+| 4.0.0 | 13.9 ms | 2.5 µs |
+| 4.0.2 | 14.4 ms | 2.5 µs |
+| 4.1.0 | 11.7 ms | 13.4 µs |
+| 4.2.0 | 9.4 ms | 2.3 µs |
+
+![The versions of RootAsRole from 3.1.0 to 4.2.0 (rar-dev), measured in October 2026 with the same policy, from 1 to 10,000 tasks.](https://github.com/LeChatP/RaR-perf/raw/main/figures/26-10-27_versions/result.png)
+
+In this figure, `rar-dev` is 4.2.0, just before its release.
+
+**The time of a single rule grew with PAM.** Since 4.0.0, dosr runs the whole PAM transaction even for a task that skips the authentication: it starts PAM, checks the account, sets the credentials, then opens and closes a session. 3.1.0 did not call PAM at all for such a task. The account check is what refuses an account that has expired, or that may not log in at this hour; sudo runs it too for a `NOPASSWD` rule. This cost is therefore kept, as a security choice. Measured commit by commit, it added about 5 ms to a run. Part of it comes from `pam_unix`, which starts its `unix_chkpwd` helper to read the account, because dosr runs as the user with file capabilities instead of being setuid root. The rest of the difference, about 1.5 ms during 3.2 and 1 ms at the end of 4.0, was not traced to a single commit.
+
+**The cost of each rule grew with patterns.** In 4.1.0, the command paths of the policy that contain wildcards were fixed: they never matched before (commit `1c3084f`). The fix matches them with globset patterns. But it compiled every command path of the policy as a pattern, even a path without any wildcard, which costs about 10 µs for each command of each task. In the same release, other changes made a run with a single rule about 2.7 ms faster.
+
+## RootAsRole 4.2.0
+
+4.2.0 now implement performance indicators unit tests, ignored by default, that print the cost of one task, so that a change can be measured before and after it:
+
+```sh
+cargo test --release --all-features --lib -- --ignored --nocapture --test-threads=1 finder::tests::perf
+```
+
+With 4.2.0, a run with one rule takes 9.4 ms, and each additional rule costs 2.3 µs. More than half of a run is the PAM transaction, which a timing probe measured at about 5.6 ms.
+
+The other tools, measured the same way on the same machine:
+
+![dosr 4.2.0, sudo, doas and please, from 1 to 10,000 rules, measured in October 2026.](https://github.com/LeChatP/RaR-perf/raw/main/figures/26-10-27_tools/result.png)
+
+| tool | one rule | 10,000 rules | each additional rule |
+|---|---|---|---|
+| dosr 4.2.0 | 9.4 ms | 30.1 ms | 2.1 µs |
+| sudo 1.9.17 | 10.5 ms | 41.1 ms | 3.0 µs |
+| doas 6.4 | 2.0 ms | 186 ms | 18.4 µs |
+| please 0.5.6 | 5.3 ms | 1,675 ms | 167 µs |
+
+`/usr/bin/true` alone takes 0.7 ms. With one rule, most of the time of dosr and sudo is the PAM transaction, which doas and please programs do not run when they ask no password. As the policy grows, the cost of each rule depends on how the tool reads and compares its rules. The policy of this figure is written by confgen, and the one of the versions by genpol, which is why the numbers of dosr differ slightly between the two.
+
 ## Large-Scale Automation
 
 This scalability improvement is particularly important in automation environments.
 
 Tools such as Ansible frequently invoke privilege escalation through `become: true` configuration option. With RaR, every role and task can introduce additional access control rules, potentially resulting in thousands of policy entries on a single system.
 
-The benchmark results show that this additional security granularity does not introduce a proportional performance cost. The optimized dosr engine can reach the execution time of a single sudo rule while evaluating approximately 4,000 RaR rules.
+The benchmark results show that this additional security granularity does not introduce a proportional performance cost. With 4.2.0, a policy of 10,000 tasks adds about 21 ms to a run.
 
 This enables administrators to define significantly more precise privilege policies while maintaining operational efficiency.
 
@@ -57,5 +113,4 @@ For comparison, **sudo-rs** provides performance comparable to sudo in standard
 
 One potential direction is the integration of a SQLite-based policy backend. The RBAC model of RaR map to relational data structures. A relational database could provide additional advantages as we could do efficient indexing as an example.
 
-The benchmarks presented above were performed in July 2025. Since then, additional performance optimisations have been implemented across the codebase, improving internal execution paths and reducing overhead further.
- @@billo2025
+The figures of the first engine were measured in 2025, with the scripts of that time. @@billo2025