v3.1.3

.github/workflows/build.yml

@@ -27,16 +27,16 @@ jobs:
         account required                    pam_permit.so
         session [success=1 default=ignore]  pam_permit.so
         session requisite                   pam_permit.so
-        session required                    pam_permit.so" | tee /etc/pam.d/sr'
+        session required                    pam_permit.so" | tee /etc/pam.d/dosr'
     - name: Install RootAsRole
       run: cargo xtask install -bip sudo
     - name: print config
-      run: sr cat /etc/security/rootasrole.json
+      run: dosr cat /etc/security/rootasrole.json
     - name: getenv
       run: env
-    - name: Run Sr
+    - name: Run dosr
       env:
         RUST_LOG: debug
-      run: /usr/bin/sr -h
-    - name: Run Chsr with sr
-      run: sr /usr/bin/chsr -h
+      run: /usr/bin/dosr -h
+    - name: Run Chsr with dosr
+      run: dosr /usr/bin/chsr -h

.vscode/launch.json

@@ -8,7 +8,7 @@
             "type": "lldb",
             "request": "launch",
             "name": "Launch",
-            "program": "${workspaceFolder}/target/debug/sr",
+            "program": "${workspaceFolder}/target/debug/dosr",
             "args": ["ls"],
             "cwd": "${workspaceFolder}"
         }

.vscode/tasks.json

@@ -14,7 +14,7 @@
             "args": [
                 "/usr/bin/setcap",
                 "=p",
-                "${cwd}/bin/sr"
+                "${cwd}/bin/dosr"
             ],
             "options": {
                 "cwd": "${cwd}"

Cargo.toml

@@ -4,11 +4,11 @@ members = ["xtask", "rar-common"]
 [package]
 name = "rootasrole"
 # The project version is managed on json file in resources/rootasrole.json
-version = "3.1.1"
+version = "3.1.3"
 rust-version = "1.76.0"
 authors = ["Eddie Billoir <[email protected]>"]
 edition = "2021"
-default-run = "sr"
+default-run = "dosr"
 description = "An alternative to sudo that uses Linux capabilities and Role based access control."
 license = "LGPL-3.0-or-later"
 repository = "https://github.com/LeChatP/RootAsRole"
@@ -41,7 +41,7 @@ debug = true
 #srlibs = [ "pam-client", "bitflags" ]
 
 [[bin]]
-name = "sr"
+name = "dosr"
 path = "src/sr/main.rs"
 required-features = ["finder"]
 
@@ -64,7 +64,7 @@ serde_json = "1.0"
 toml = "0.8"
 
 [dependencies]
-rar-common = { path = "rar-common", version = "3.1.0", package = "rootasrole-core" }
+rar-common = { path = "rar-common", version = "3.1.3", package = "rootasrole-core" }
 log = "0.4"
 libc = "0.2"
 strum = { version = "0.26", features = ["derive"] }
@@ -76,8 +76,7 @@ serde = { version = "1.0", features=["rc", "derive"] }
 serde_json = "1.0"
 cbor4ii = { version = "1.0.0", features = ["serde", "serde1", "use_std"] }
 glob = "0.3"
-pam-client2 = "0.5"
-bitflags = { version = "2.6" }
+bitflags = { version = "2.9" }
 shell-words = "1.1"
 linked_hash_set = { version = "0.1" }
 derivative = "2.2"
@@ -89,9 +88,11 @@ pest = "2.7"
 pest_derive = "2.7"
 const_format = "0.2"
 hex = "0.4"
-bon = "3.5.1"
-serde_json_borrow = "0.7.1"
-konst = "0.3.16"
+bon = "3"
+serde_json_borrow = "0.8"
+konst = "0.3"
+nonstick = "0.1.1"
+libpam-sys = "0.2.0"
 
 [dev-dependencies]
 log = "0.4"
@@ -121,7 +122,7 @@ changelog = "target/debian/changelog"
 
 [package.metadata.generate-rpm]
 assets = [
-    { source = "target/release/sr", dest = "/usr/bin/sr", user = "root", group = "root", mode = "0555", caps = "=p" },
+    { source = "target/release/dosr", dest = "/usr/bin/dosr", user = "root", group = "root", mode = "0555", caps = "=p" },
     { source = "target/release/chsr", dest = "/usr/bin/chsr", user = "root", group = "root", mode = "0555" },
     { source = "resources/rh/rh_sr_pam.conf", dest = "/etc/pam.d/sr", user = "root", group = "root", mode = "0644", config = true },
     { source = "resources/rootasrole.json", dest = "/etc/security/rootasrole.json", user = "root", group = "root", mode = "0644", config = true },

README.md

@@ -14,7 +14,7 @@
 <!-- The project version is managed on json file in resources/rootasrole.json -->
 <!-- markdownlint-restore -->
 
-# RootAsRole (V3.1.1) — A better alternative to `sudo(-rs)`/`su` • ⚡ Blazing fast • 🛡️ Memory-safe • 🔐 Security-oriented
+# RootAsRole (V3.1.3) — A better alternative to `sudo(-rs
 
 RootAsRole is a Linux/Unix privilege delegation tool based on **Role-Based Access Control (RBAC)**. It empowers administrators to assign precise privileges — not full root — to users and commands.
 
@@ -44,7 +44,7 @@ RootAsRole solves this:
 
 ## 📊 Why It’s Better Than Others
 
-| Feature                                  | setcap??          | doas       | sudo                           | sudo-rs                       | sr (RootAsRole)                                          |
+| Feature                                  | setcap??          | doas       | sudo                           | sudo-rs                       | dosr (RootAsRole)                                          |
 |------------------------------------------|-------------------|------------|--------------------------------|--------------------------------|----------------------------------------------|
 | **Change user/groups**                   | N/A               | ✅  | ✅ | ✅ | ✅✅ mandatory or optional                       |
 | **Environment variables**                | N/A               | partial  | ✅ | partial                     | ✅                                    |
@@ -97,7 +97,7 @@ RootAsRole solves this:
 <pre>
 Execute privileged commands with a role-based access control system
 
-<u><b>Usage</b></u>: <b>sr</b> [OPTIONS] [COMMAND]...
+<u><b>Usage</b></u>: <b>dosr</b> [OPTIONS] [COMMAND]...
 
 <u><b>Arguments</b></u>:
   [COMMAND]...  Command to execute
@@ -116,7 +116,8 @@ Execute privileged commands with a role-based access control system
 
 If you're accustomed to utilizing the sudo tool and find it difficult to break that habit, consider creating an alias : 
 ```sh
-alias sudo="sr"
+alias sudo="dosr"
+alias sr="dosr"
 ```
 
 ## 🏎️ Performance
@@ -132,7 +133,7 @@ RootAsRole **3.1.0** introduced **CBOR** support, significantly boosting perform
 
 ### Why Performance Matters
 
-When using **Ansible** (or any automation tool), every task that uses `become: true` will invoke `sr` on the target host.
+When using **Ansible** (or any automation tool), every task that uses `become: true` will invoke `dosr` on the target host.
 With **RootAsRole (RaR)**, each role and task introduces additional access control logic --- this doesn’t slow you down.
 
 💡 **Here’s the reality**: You can reach the performance of **1 `sudo` rule** with **~4000 RaR rules**.

book/src/README.md

@@ -17,13 +17,13 @@
 
 ## Usage
 
-The main command line tool is `sr`. It allows you to execute a command by simply typing:
+The main command line tool is `dosr`. It allows you to execute a command by simply typing:
 
 ```bash
-sr <command>
+dosr <command>
 ```
 
-You can find more information about this command in the [sr](sr/README.md) section.
+You can find more information about this command in the [dosr](sr/README.md) section.
 
 The `chsr` command allows you to configure the roles and capabilities of the system. You can find more information about this command in the [Configure RootAsRole](chsr/README.md) section.
 
@@ -51,43 +51,43 @@ By using a role-based access control model, this project allows us to better man
 You are using your personal computer and you want to install a new package. By default, RootAsRole add one role with 2 tasks : one task for using `chsr` command that grant only the `CAP_LINUX_IMMUTABLE` capability as `root` user (unprivileged), and one task for all commands but without `CAP_LINUX_IMMUTABLE` privilege. As installing a package may require almost all capabilities, you can use the default role to install a package. Indeed, if you wish to install apache2, you'll need `CAP_NET_BIND_SERVICE`, if you install docker you'll need many privileges, virtualbox needs `CAP_SYS_MODULE`, etc. So, you can use the default role to install a package:
 
 ```bash
-sr apt install <package>
+dosr apt install <package>
 ```
 
 ### Scenario 2: Granting users the right to restart their system
 
 You are the system administrator of a company and you want to delegate the right to restart the server to a user. You can use `chsr` to create a role and grant the right to restart the server to users.
 
 ```bash
-sr chsr role r_users add # Create a new role
-sr chsr role r_users grant -g users # Grant the role to the group users
-sr chsr role r_users task t_reboot add # Create a new task
-sr chsr role r_users task t_reboot cmd whitelist add reboot # Add the reboot command to the task
-sr chsr role r_users task t_reboot cred caps whitelist add CAP_SYS_BOOT # Add the CAP_SYS_BOOT capability to the task
+dosr chsr role r_users add # Create a new role
+dosr chsr role r_users grant -g users # Grant the role to the group users
+dosr chsr role r_users task t_reboot add # Create a new task
+dosr chsr role r_users task t_reboot cmd whitelist add reboot # Add the reboot command to the task
+dosr chsr role r_users task t_reboot cred caps whitelist add CAP_SYS_BOOT # Add the CAP_SYS_BOOT capability to the task
 ```
 
 Then users can restart the server with the following command:
 
 ```bash
-sr reboot
+dosr reboot
 ```
 
 ### Scenario 3 : Passing environment variables to a command
 
 You are a developer and you want to pass environment variables to a command. For example with sudo you can use the `-E` option to pass environment variables to a command. With RootAsRole, you'll need to setup a role with a task that allows the command to use environment variables. However, as you keep the default configuration, you'll have two roles that matches ANY commands, and if the first one is more restrictive than the second one, you'll need to specify the role to use. Here is an example:
 
 ```bash
-sr chsr role env add # Create a new role
-sr chsr role env task env add # Create a new task
-sr chsr role env task env cmd setpolicy allow-all # Add all command to the task
-sr chsr role env task env cred caps setpolicy allow-all # Add all capabilities to the task
-sr chsr role env task env o env setpolicy keep-all # Keep the environment variables
+dosr chsr role env add # Create a new role
+dosr chsr role env task env add # Create a new task
+dosr chsr role env task env cmd setpolicy allow-all # Add all command to the task
+dosr chsr role env task env cred caps setpolicy allow-all # Add all capabilities to the task
+dosr chsr role env task env o env setpolicy keep-all # Keep the environment variables
 ```
 
 Then you can use the following command to pass environment variables to a command:
 
 ```bash
-sr -r env [command]
+dosr -r env [command]
 ```
 
 This is because the default role do not keep the environment variables, so if you want to keep environment variables you need to specify the role to use.
@@ -97,26 +97,26 @@ This is because the default role do not keep the environment variables, so if yo
 You are an administrator that want to automatically reboot the system at 04:05 every day with cron for example. You can disable authentication by setting skip-auth in the options. Here is an example:
 
 ```bash
-sr chsr role auto add # Create a new role
-sr chsr role grant -u cron # Grant the role to the user cron
-sr chsr role auto task cron_reboot add # Create a new task
-sr chsr role auto task cron_reboot cmd whitelist add reboot # Add the reboot command to the task
-sr chsr role auto task cron_reboot cred caps whitelist add CAP_SYS_BOOT # Add the CAP_SYS_BOOT capability to the task
-sr chsr role auto task cron_reboot o authentication skip # Skip authentication
+dosr chsr role auto add # Create a new role
+dosr chsr role grant -u cron # Grant the role to the user cron
+dosr chsr role auto task cron_reboot add # Create a new task
+dosr chsr role auto task cron_reboot cmd whitelist add reboot # Add the reboot command to the task
+dosr chsr role auto task cron_reboot cred caps whitelist add CAP_SYS_BOOT # Add the CAP_SYS_BOOT capability to the task
+dosr chsr role auto task cron_reboot o authentication skip # Skip authentication
 ```
 
 Then you can configure the cron to reboot the system with the following command:
 
 ```bash
-sr crontab -u cron -e
+dosr crontab -u cron -e
 ```
 
 and add the following line to reboot the system at 04:05 every day
 
 ```cron
-5 4 * * * sr -r auto -t cron_reboot reboot
+5 4 * * * dosr -r auto -t cron_reboot reboot
 ```
 
-Note: You should consider to set the `-r auto -t cron_reboot` options to the `sr` command when you automate a task to avoid any security issue or future conflict.
+Note: You should consider to set the `-r auto -t cron_reboot` options to the `dosr` command when you automate a task to avoid any security issue or future conflict.
 
 For a more complete example, you can checkout the [Is a Linux system without root user possible ?](knowledge/no-root.md) section.

book/src/SUMMARY.md

@@ -6,7 +6,7 @@
 # User Guide
 
 - [Installation](guide/installation.md)
-- [`sr` Command Line Tool](sr/README.md)
+- [`dosr` Command Line Tool](dosr/README.md)
 - [`chsr` Command Line Tool](chsr/README.md)
 - [`capable` Command Line Tool](capable/README.md)
 

book/src/chsr/file-config.md

@@ -93,9 +93,9 @@ The following example shows a RootAsRole config without plugins when almost ever
           "cred": {
             "setuid": {
               "fallback": "thefallbackuser", // Fallback user if the -u option is not set
-              "default": "none", // The sr user cannot use -u option in general
-              "add": ["theuser"], // the sr user can use "-u theuser" option
-              "sub": ["anotheruser"] // the sr user cannot use "-u anotheruser" option (overrides add, applies only if default is all)
+              "default": "none", // The dosr user cannot use -u option in general
+              "add": ["theuser"], // the dosr user can use "-u theuser" option
+              "sub": ["anotheruser"] // the dosr user cannot use "-u anotheruser" option (overrides add, applies only if default is all)
             }, // User to setuid before executing the command
             "setgid": [ // Groups to setgid before executing the command, The first one is the primary group
               "group1",

book/src/sr/README.md → book/src/dosr/README.md

@@ -1,11 +1,11 @@
-# What is sr tool
+# What is dosr tool
 
-`sr` is the abbrevation of "switch role" is a command line tool like sudo. It allows a permitted user to execute a command as another user and groups. More than sudo it allows to a permitted user to obtain some privileges. The sr command is used to switch to a role.
+`dosr` is the abbrevation of "do switch role" is a command line tool like sudo. It allows a permitted user to execute a command as another user and groups. More than sudo it allows to a permitted user to obtain some privileges. The sr command is used to switch to a role.
 
 # Usage
 
 <pre>
-<u><b>Usage</b></u>: <b>sr</b> [OPTIONS] [COMMAND]...
+<u><b>Usage</b></u>: <b>dosr</b> [OPTIONS] [COMMAND]...
 
 <u><b>Arguments</b></u>:
   [COMMAND]...  Command to execute

book/src/guide/installation.md

@@ -28,12 +28,12 @@ Install script does the following:
 - Dependency Step :
   - Installing necessary dependencies considering if compiling from source.
 - Build Step :
-  - Building sr and chsr binaries
+  - Building dosr and chsr binaries
 - Install Step : 
-  - Copying sr and chsr binaries to /usr/bin
-  - Setting all capabilities on /usr/bin/sr
-  - Setting owners and permissions on /usr/bin/sr
+  - Copying dosr and chsr binaries to /usr/bin
+  - Setting all capabilities on /usr/bin/dosr
+  - Setting owners and permissions on /usr/bin/dosr
 - Configuration Step :
-  - Deploying /etc/pam.d/sr for PAM configuration
+  - Deploying /etc/pam.d/dosr for PAM configuration
   - Deploying /etc/security/rootasrole.json for configuration
   - Setting immutable on /etc/security/rootasrole.json if filesytem supports it

book/src/knowledge/no-root.md

@@ -3,35 +3,35 @@
 To make it short, not really. But you can design your system to never have to use the root user. This is what RootAsRole aims, and the exact purpose of Linux Capabilities. Let's consider you want a system without root user and you want to setup a webserver. Firstly, let's create the apache2 user and group:
 
 ```bash
-sr adduser apache2
+dosr adduser apache2
 ```
 
 We consider that we still use the default configuration of RootAsRole. Then, let's add a task to install apache2 with the apache2 user:
 
 ```bash
-sr chsr r r_root t install_apache2 add
-sr chsr r r_root t install_apache2 cmd whitelist add apt install apache2
-sr chsr r r_root t install_apache2 cmd whitelist add "apt upgrade( -y)? apache2"
-sr chsr r r_root t install_apache2 cred set --caps CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_NET_BIND_SERVICE,CAP_SETUID --setuid apache2 --setgid apache2
+dosr chsr r r_root t install_apache2 add
+dosr chsr r r_root t install_apache2 cmd whitelist add apt install apache2
+dosr chsr r r_root t install_apache2 cmd whitelist add "apt upgrade( -y)? apache2"
+dosr chsr r r_root t install_apache2 cred set --caps CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_NET_BIND_SERVICE,CAP_SETUID --setuid apache2 --setgid apache2
 ```
 
 Then, let's add a task to start apache2 with the apache2 user:
 
 ```bash
-sr chsr r r_root t start_apache2 add
-sr chsr r r_root t start_apache2 cmd whitelist add "systemctl ((re)?start|stop) apache2"
-sr chsr r r_root t start_apache2 cmd whitelist add "service apache2 ((re)?start|stop)"
-sr chsr r r_root t install_apache2 cred set --caps CAP_NET_BIND_SERVICE,CAP_SETUID --setuid apache2 --setgid apache2
+dosr chsr r r_root t start_apache2 add
+dosr chsr r r_root t start_apache2 cmd whitelist add "systemctl ((re)?start|stop) apache2"
+dosr chsr r r_root t start_apache2 cmd whitelist add "service apache2 ((re)?start|stop)"
+dosr chsr r r_root t install_apache2 cred set --caps CAP_NET_BIND_SERVICE,CAP_SETUID --setuid apache2 --setgid apache2
 ```
 
 So now you can install and start apache2 with the apache2 user:
 
 ```bash
-sr apt install apache2
+dosr apt install apache2
 ```
 
 This should install apache2 configuration files owned by apache2 user and group. Then you can start apache2 with the apache2 user:
 
 ```bash
-sr systemctl start apache2
+dosr systemctl start apache2
 ```

build.rs

@@ -74,6 +74,10 @@ fn main() {
         eprintln!("cargo:warning={}", err);
     }
 
+    if let Err(err) = set_cargo_version(&package_version, "Cargo.toml") {
+        eprintln!("cargo:warning={}", err);
+    }
+
     if let Err(err) = set_readme_version(&package_version, "README.md") {
         eprintln!("cargo:warning={}", err);
     }