RootAsRole(8)

📦 version 4.0.0, in ubuntu stonking

💖 RootAsRole — the System Manager's Manual glow-up 💖

okay bestie, sit down, hydrate, and let me tell you about RootAsRole(8) 🫶 — it's the alternative to sudo/su commands that actually adheres to the principle of least privilege and gives you more secure memory management. it's giving responsible baddie energy, fr fr. 👑

✨ SYNOPSIS ✨

no cap, there's two whole commands and they're both kinda iconic:

dosr [OPTIONS] [COMMAND]...
chsr [ARGUMENTS]

and listen — chsr's arguments follow a grammar, and that grammar lives right here, you can go look at it yourself: https://github.com/LeChatP/RootAsRole/tree/main/src/chsr/cli/cli.pest 🎀

🌸 DESCRIPTION 🌸

so RootAsRole is a tool for administrators, and what it does is give you a structured role-based access control (RBAC) system so you can delegate administrative tasks and access rights without just handing someone the whole kingdom. it specifically supports Linux capabilities(7) to keep user privileges as smol as possible. 💅

the RBAC model is built on sets of permissions assigned to users or groups. in RootAsRole, a role is a set of administrative tasks assigned to users. tasks are commands with specific rights. and those rights can include changing the user, changing the group, or/and using Linux capabilities. that's the whole vibe. ✨

now, the dosr command is the one that lets you execute commands using a role. it requires a command to be executed as a mandatory parameter (yes mandatory, it's not optional bestie, it needs a command). you can also specify a role and a task to select.

here's where it gets lowkey smart: sometimes several tasks match a user's command input. when that happens, dosr selects the most precise and least privileged task. "precision" here means how closely the RootAsRole policy matches the user's command — the more the user's profile matches the policy, the higher the level of precision. same logic applies to how precisely the user's command matches its spec in the policy. and similarly, the task with fewer privileges gets prioritized over a task with higher privileges... but only if the tasks are equally precise. despite all this intelligent selection, confusion can still arise, and you'll get an error message. 😭

example of a confusion case: two roles are assigned in the same way to a user, and among these roles, two tasks are entirely equivalent, but the configured environment variables are different for those two tasks. dosr will then display Permission denied and log a warning that the configuration must be fixed. this case should not happen if administrators are using chsr, the configuration tool. (so like... use chsr, bestie 🎀)

you can change the user's prompt with the -p option — cute. you can also view the executor's rights with the -i option, though the info displayed is very limited for the user. if you're an administrator, use chsr to get the complete policy. that's where the full tea is. ☕

the chsr command is the config tool — it configures RootAsRole and its access control policy, letting you set up roles, tasks, and permissions. the config is stored in /etc/security/rootasrole.json. and here's the spicy part: if the file system supports it, the file is made immutable, which means you need the CAP_LINUX_IMMUTABLE privilege to use chsr. the default RootAsRole policy grants the installer the possibility to use chsr with the necessary privileges. 🫶

the storage mode of the access control policy can be configured, too. by default RootAsRole uses a JSON file, and you can change the storage mode by manually modifying /etc/security/rootasrole.json. ✨

on authentication: RootAsRole uses Pluggable Authentication Module (PAM). the /etc/pam.d/dosr file can be configured to change authentication behavior. 🦋

and about the core: RootAsRole implements RBAC-0, a simplified version of RBAC. by default it adds features in the form of plugins to implement certain RBAC-1 functionalities. RBAC-0 simply implements roles, tasks, and permissions, while plugins add role hierarchy and separation of duties. plugins can only be implemented directly in the project. another plugin allows testing the checksum of executed files. the way that's structured... obsessed. 🌈

💅 OPTIONS 💅

  • -r, --role <ROLE> — choose a specific role.
  • -t, --task <TASK> — choose a specific task within a role (this one requires --role, don't forget it bestie).
  • -u USER, --user <USER> — execute the command as a specific user (it acts as a filter to select a task).
  • -g GROUP(,GROUP...), --group <GROUP(,GROUP...)> — execute the command as specific group(s) (also acts as a filter to select a task).
  • -E, --preserve-env — preserve environment variables from the current process, if allowed by a matching task.
  • -p, --prompt <PROMPT> — prompt to display when authenticating.
  • -K, --remove-timestamp — remove timestamp cookie before authentication.
  • -i, --info — print the execution context of a command if allowed by a matching task.
  • -h, --help — print help (you get more with --help').
  • -v, --version — print version information.

🍓 EXAMPLES 🍓

okay actual real usage, here we go:

dosr reboot

that one executes the reboot command (if the policy allows it, obviously 🌸).

dosr -r dac chmod 644 /etc/foo/bar

and this one executes the command chmod 644 /etc/foo/bar with the role dac (if the policy has a dac role and a task that allows the chmod command). slay. 💅

👑 HISTORY 👑

you can find the history of RootAsRole on the website right here, go read it, it's lore: https://lechatp.github.io/RootAsRole/HISTORY.html 🦋

🚨 SECURITY RISKS 🚨

okay this part is the serious part, pay attention, no skimming:

RootAsRole is a security tool that can give a user full control of the system. an administrator can write an access control policy that gives too many privileges to a user. and a Perl-compatible regular expression (pcre2) library is very complex and may accept unexpected special characters. 😳

it can be challenging to determine the necessary privileges for a command. for this, you can use the capable tool available at https://github.com/LeChatP/RootAsRole-capable/ to determine the required capabilities for a command. however — this tool might give too many capabilities. it is recommended to verify if the capabilities are truly necessary, as in most cases, they are not. and it is discouraged to use capable in production, as it is only for testing purposes. periodt. 💀

🫶 SUPPORT 🫶

for help, please visit https://github.com/LeChatP/RootAsRole/discussions — or https://github.com/LeChatP/RootAsRole/issues if you find a bug. 🐛 we got you bestie.

📜 DISCLAIMER 📜

this program is provided "as is" without any warranty, to the extent permitted by law. the authors disclaim any responsibility for the quality or suitability of the program for a particular purpose. you use this program at your own risk. in case of problems, you are responsible for any necessary repairs or corrections. for more details, please refer to the GNU LGPL version 3 or later: https://www.gnu.org/licenses/lgpl-3.0.html 💜

🌈 LICENSE 🌈

LGPLv3+: GNU LGPL version 3 or later https://www.gnu.org/licenses/lgpl-3.0.html. ✨

💖 SEE ALSO 💖

Linux capabilities(7), sudo(8), su(1) — go read the extended universe, iykyk 📚

🎀 AUTHORS 🎀

Eddie Billoir lechatp@outlook.fr 💌

and that's the whole page, bestie. this was RootAsRole 4.0.0, from August 2025 — written with love, secured with least privilege, and yes, the system manager's manual could never be boring again. now go configure your roles like the main character you are. 🧚✨💅

📦 where this page comes from