Sudo Rule Management

Overview

Sudo rules in FreeIPA provide centralized, auditable management of privilege escalation across IPA-enrolled systems. Rather than maintaining local /etc/sudoers files on each system, administrators define sudo rules in IPA which are distributed to clients through SSSD. This centralization enables consistent privilege policies, simplified administration, and comprehensive audit trails of privileged command execution.

Each sudo rule defines a relationship between who (users/groups), where (hosts/hostgroups), what (commands/command groups), and as whom (RunAs users/groups). When a user attempts to execute a command via sudo, the client evaluates applicable rules to determine whether the operation is permitted. Multiple rules can apply to a single operation, with allow and deny commands providing fine-grained control over privileged access.

Sudo rules integrate with IPA’s group and host group infrastructure, enabling privilege delegation that automatically adapts as organizational structure changes. When users join groups or hosts join host groups, their sudo privileges automatically adjust according to rules targeting those groups. This dynamic membership eliminates manual sudoers file updates and ensures privilege assignments remain current.

Rule Components

Users and User Groups

The “who” dimension defines which users are affected by the rule. Individual users can be specified directly, or groups can be referenced to apply rules to collections of users. User category “all” creates rules applying to every IPA user, though such broad rules should be used cautiously as they grant universal privilege potential.

External users from trusted Active Directory domains can be included in sudo rules using external user identifiers. This enables AD users to have sudo privileges on IPA-managed systems without requiring local IPA user accounts.

When multiple rules apply to a user, all allow commands from all applicable rules are available. Deny commands take precedence over allow commands, enabling exception-based policy where broad access is granted then specific commands are prohibited.

Hosts and Host Groups

The “where” dimension specifies which hosts the rule applies to. Individual hosts can be targeted for host-specific privilege grants, or host groups enable privilege delegation across fleets of similar systems. Host category “all” creates rules applying on every enrolled IPA client.

Host targeting enables role-based privilege models: database administrators might have sudo access to database servers but not web servers, while web administrators have the inverse. This compartmentalization limits blast radius if credentials are compromised.

Combined with host groups, sudo rules support infrastructure-as-code patterns where provisioning systems automatically place new hosts into appropriate host groups, inheriting correct sudo policies without manual configuration.

Allowed and Denied Commands

Sudo rules specify which commands users can execute. Commands are represented as sudo command objects (created with sudocmd-add) defining command paths and optional argument restrictions. Sudo command groups collect related commands for easier rule management.

Allow commands grant permission to execute specific commands. Users can execute any command allowed by any applicable rule. Deny commands explicitly prohibit specific commands, taking precedence over allow directives. This enables pattern like “allow all commands except password changes.”

Command category “all” permits execution of any command (equivalent to ALL in sudoers). While convenient, “all” rules should be limited to highly trusted administrators as they grant unrestricted root access.

Arguments to sudo commands can include argument restrictions in the command definition itself. For example, /usr/bin/systemctl restart httpd permits only that specific invocation, while /usr/bin/systemctl without arguments permits any systemctl operation.

RunAs Users and Groups

The “as whom” dimension specifies which user identity sudo assumes when executing commands. By default, sudo executes as root, but RunAs specifications enable running commands as arbitrary users. This supports workflows requiring specific user contexts without granting full root access.

RunAs users specify individual users or user groups. For example, a rule might allow web administrators to run commands as the apache user to manage web server processes. RunAs groups specify the group context for command execution, controlling file ownership and permissions for created files.

External RunAs users and groups enable running commands as AD users or groups, supporting cross-domain privilege delegation in trust relationships.

Category “all” for RunAs users permits execution as any user on the system, essentially granting unrestricted sudo access. This powerful capability should be restricted to highly privileged administrators.

Sudo Options

Sudo options modify sudo behavior, replicating sudoers configuration options in IPA-managed rules. Common options include:

!authenticate: Disables password prompting (equivalent to NOPASSWD). Use cautiously as it weakens accountability by allowing passwordless privilege escalation.

mail_badpass: Sends email when incorrect passwords are entered, aiding security monitoring.

env_keep: Preserves environment variables during sudo execution. Each variable requires a separate option (e.g., env_keep=PATH, env_keep+=HOME).

type and role: Sets SELinux type and role transitions for the command, enabling SELinux policy integration with sudo privilege delegation.

Sudo options require exact sudo syntax and are not validated by IPA. Incorrect option syntax may cause sudo failures on clients. Test sudo options thoroughly before deploying to production systems.

The special rule named “defaults” contains global sudo options applying to all sudo operations on IPA clients, replicating the “Defaults” directive in traditional sudoers files.

Rule Ordering

Sudo rules can include an order attribute controlling evaluation sequence. While SSSD processes all applicable rules regardless of order, some sudo configurations respect rule ordering for conflict resolution or priority determination.

Orders are specified as unique integers. Lower numbers evaluate first. Order values need not be contiguous (orders 10, 20, 30 work as well as 1, 2, 3) and gaps between order values provide flexibility for inserting rules later without renumbering.

When order is not specified or not supported by the client, all applicable rules are evaluated and their allow/deny commands are merged. Deny commands always take precedence over allow commands regardless of rule order.

External User Support

Sudo rules support external users from trusted Active Directory forests. External users are identified by SID or domain\username format. When AD users authenticate to IPA-enrolled systems, their sudo privileges are evaluated including rules targeting external users.

External RunAs users enable sudo operations running as AD users, supporting scenarios where AD service accounts manage infrastructure on IPA-enrolled systems without requiring duplicate IPA accounts.

External user sudo rules require proper trust configuration between IPA and Active Directory. The trust must be established and functional before external users can authenticate or be referenced in sudo rules.

Sudo Bind DN

IPA provides a dedicated LDAP bind DN for sudo queries: uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com. Some legacy sudo configurations query LDAP directly rather than using SSSD. For these configurations, setting a password on the sudo bind DN enables authentication.

Modern IPA deployments use SSSD for sudo integration, eliminating direct LDAP queries and the need for sudo bind DN passwords. SSSD caches sudo rules locally, improving performance and enabling offline sudo operation when IPA servers are unreachable.

The sudo bind DN is provided for backward compatibility. New deployments should configure SSSD sudo integration rather than direct LDAP queries.

Examples

Basic Rule Management

Create a new sudo rule:

ipa sudorule-add restart_services --desc="Allow service restarts"

Create a rule with all categories (unrestricted - use cautiously):

ipa sudorule-add admin_all --usercat=all --hostcat=all --cmdcat=all

Delete a sudo rule:

ipa sudorule-del restart_services

Display rule details:

ipa sudorule-show restart_services --all

Search for rules by name pattern:

ipa sudorule-find restart

Find all enabled rules:

ipa sudorule-find --enabled=TRUE

Find rules affecting a specific user:

ipa sudorule-find --users=jsmith

User Assignment

Add individual users to a rule:

ipa sudorule-add-user restart_services --users=jsmith

Add multiple users:

ipa sudorule-add-user restart_services --users=jsmith --users=alee

Add user groups to a rule:

ipa sudorule-add-user restart_services --groups=sysadmins

Add both users and groups:

ipa sudorule-add-user restart_services --users=jsmith --groups=operators

Remove users from a rule:

ipa sudorule-remove-user restart_services --users=jsmith

Host Assignment

Add individual hosts to a rule:

ipa sudorule-add-host restart_services --hosts=web01.example.com

Add host groups:

ipa sudorule-add-host restart_services --hostgroups=webservers

Add multiple hosts and hostgroups:

ipa sudorule-add-host restart_services --hosts=web01.example.com --hostgroups=databases

Remove hosts from a rule:

ipa sudorule-remove-host restart_services --hosts=web01.example.com

Command Management

Create sudo commands first:

ipa sudocmd-add /usr/bin/systemctl
ipa sudocmd-add '/usr/bin/systemctl restart httpd'
ipa sudocmd-add /usr/sbin/reboot

Add allowed commands to a rule:

ipa sudorule-add-allow-command restart_services --sudocmds='/usr/bin/systemctl restart httpd'

Create and use sudo command groups:

ipa sudocmdgroup-add service_management
ipa sudocmdgroup-add-member service_management --sudocmds='/usr/bin/systemctl'
ipa sudorule-add-allow-command restart_services --sudocmdgroups=service_management

Add denied commands (take precedence over allowed):

ipa sudorule-add-deny-command restart_services --sudocmds='/usr/sbin/reboot'

Remove allowed commands:

ipa sudorule-remove-allow-command restart_services --sudocmds='/usr/bin/systemctl'

RunAs Configuration

Configure RunAs users (run commands as specific user):

ipa sudorule-add-runasuser web_management --users=apache

Add RunAs user groups:

ipa sudorule-add-runasuser app_management --groups=appusers

Configure RunAs groups (set group context):

ipa sudorule-add-runasgroup log_management --groups=adm

Remove RunAs users:

ipa sudorule-remove-runasuser web_management --users=apache

Sudo Options

Create defaults rule for global sudo options:

ipa sudorule-add defaults --desc="Global sudo defaults"

Add option to disable password prompting:

ipa sudorule-add-option restart_services --sudooption='!authenticate'

Add multiple options:

ipa sudorule-add-option restart_services --sudooption='!authenticate' --sudooption='mail_badpass'

Preserve environment variables:

ipa sudorule-add-option app_management --sudooption='env_keep=PATH'
ipa sudorule-add-option app_management --sudooption='env_keep+=HOME'
ipa sudorule-add-option app_management --sudooption='env_keep+=LANG'

Set SELinux context transitions:

ipa sudorule-add-option selinux_admin --sudooption='type=unconfined_t'
ipa sudorule-add-option selinux_admin --sudooption='role=unconfined_r'

Remove sudo options:

ipa sudorule-remove-option restart_services --sudooption='!authenticate'

Rule Ordering

Set rule order (lower numbers evaluate first):

ipa sudorule-mod emergency_admin --order=10
ipa sudorule-mod regular_admin --order=20

Rule State Management

Disable a rule temporarily:

ipa sudorule-disable restart_services

Re-enable a disabled rule:

ipa sudorule-enable restart_services

External User Support (AD Integration)

Add external AD users to a rule:

ipa sudorule-add user_rule --externaluser='AD\alice'
ipa sudorule-add user_rule --externaluser='bob@ad.example.com'

Configure external RunAs users:

ipa sudorule-add-runasuser cross_domain --runasexternaluser='AD\svcaccount'

Configure external RunAs groups:

ipa sudorule-add-runasgroup cross_domain --runasexternalgroup='AD\Admins'

Complete Rule Examples

Web server management - Allow sysadmins to restart web services:

ipa sudorule-add web_restart --desc="Restart web services"
ipa sudorule-add-user web_restart --groups=sysadmins
ipa sudorule-add-host web_restart --hostgroups=webservers
ipa sudocmd-add '/usr/bin/systemctl restart httpd'
ipa sudocmd-add '/usr/bin/systemctl restart nginx'
ipa sudorule-add-allow-command web_restart --sudocmds='/usr/bin/systemctl restart httpd' --sudocmds='/usr/bin/systemctl restart nginx'

Database administration - Allow DBAs full sudo on database servers:

ipa sudorule-add dba_sudo --desc="DBA full access"
ipa sudorule-add-user dba_sudo --groups=dbas
ipa sudorule-add-host dba_sudo --hostgroups=databases
ipa sudorule-add-allow-command dba_sudo --cmdcat=all
ipa sudorule-add-runasuser dba_sudo --users=postgres --users=mysql

Limited file viewing - Allow helpdesk to read logs:

ipa sudorule-add view_logs --desc="Read system logs"
ipa sudorule-add-user view_logs --groups=helpdesk
ipa sudorule-add-host view_logs --hostcat=all
ipa sudocmd-add /usr/bin/less
ipa sudocmd-add /usr/bin/tail
ipa sudocmd-add /usr/bin/cat
ipa sudocmdgroup-add log_readers
ipa sudocmdgroup-add-member log_readers --sudocmds=/usr/bin/less --sudocmds=/usr/bin/tail --sudocmds=/usr/bin/cat
ipa sudorule-add-allow-command view_logs --sudocmdgroups=log_readers
ipa sudorule-add-option view_logs --sudooption='!authenticate'

Emergency access - Full access for specific user in emergencies:

ipa sudorule-add emergency --desc="Emergency admin access"
ipa sudorule-add-user emergency --users=emergency_admin
ipa sudorule-add-host emergency --hostcat=all
ipa sudorule-add-allow-command emergency --cmdcat=all
ipa sudorule-mod emergency --order=1
ipa sudorule-disable emergency  # Enable only during emergencies

Best Practices

Rule Design

Follow least privilege: Grant minimal necessary commands rather than broad access. Specific command rules are more secure than --cmdcat=all.

Use groups instead of individual users: Target user groups and host groups rather than individual users/hosts. This enables privilege delegation that automatically adapts as group membership changes.

Create role-based rules: Design rules around organizational roles (web admin, database admin, help desk) rather than individual people. This improves maintainability and clarity.

Separate concerns: Create multiple focused rules rather than single complex rules. For example, separate “restart services” from “modify configurations” even if the same users need both.

Document rule purposes: Use --desc to clearly explain each rule’s purpose. Future administrators will thank you.

Command Specification

Be specific with command paths: Use full paths (/usr/bin/systemctl) not relative names. This prevents PATH-based exploits.

Restrict command arguments when possible: Define commands with specific arguments (/usr/bin/systemctl restart httpd) rather than unrestricted commands when the use case permits.

Use command groups for related commands: Group related commands (web_service_management) for easier rule management and consistent policy application.

Test deny commands carefully: Deny commands override allow commands. Ensure denied commands don’t inadvertently block legitimate operations.

Sudo Options

Avoid !authenticate unless necessary: Passwordless sudo weakens accountability. Only use for automated systems or very limited commands.

Test options before production: Sudo option syntax is not validated. Test thoroughly in non-production before deploying.

Use env_keep cautiously: Preserving environment variables can introduce security risks. Only preserve variables that are truly necessary.

Monitor mail_badpass alerts: If using mail_badpass, ensure alerts are monitored. Failed sudo attempts may indicate attack attempts.

RunAs Configuration

Limit RunAs users: Don’t grant --runasusercat=all unless users truly need to run as arbitrary accounts. This is nearly equivalent to full root.

Use RunAs for least privilege: Rather than granting root access, use RunAs to execute commands as specific service accounts (apache, postgres).

Consider group context: RunAs group affects file ownership. Ensure RunAs group settings align with file permission requirements.

Security Considerations

Regular rule audits: Periodically review sudo rules to ensure they still match organizational needs and haven’t become overly permissive.

Monitor sudo usage: Review sudo logs for unusual patterns. Unexpected sudo usage may indicate compromised accounts or policy violations.

Disable unused rules: Don’t delete rules that might be needed later. Use sudorule-disable to temporarily deactivate them.

Protect emergency rules: Emergency full-access rules should normally be disabled, enabled only during actual emergencies, then disabled again.

Test rules before deployment: Create test rules and verify they work as expected before deploying to production systems. Incorrect rules can block legitimate operations or grant unintended access.

Operational Practices

Use rule ordering for precedence: When rules might conflict, use order to establish precedence. Lower numbers evaluate first.

Plan for SSSD cache refresh: Sudo rule changes may take time to reach clients due to SSSD caching. For urgent changes, flush SSSD cache or restart SSSD on affected clients.

Maintain command object library: Create sudo commands and command groups as reusable building blocks. This ensures consistency across rules.

Version control rule changes: Maintain documentation or version control tracking of sudo rule changes. This aids troubleshooting and provides rollback capability.

Coordinate with HBAC: Ensure HBAC rules permit the access that sudo rules grant. If HBAC blocks user access to a host, sudo rules on that host are moot.

External User Integration

Validate trust configuration: Before creating external user sudo rules, verify the Active Directory trust is functional and stable.

Use external groups when possible: Rather than individual external users, use external groups in sudo rules for easier management.

Document external user mappings: Maintain clear records of which AD users/groups have sudo privileges and why.

Test external user sudo carefully: External user sudo depends on trust integrity, AD reachability, and proper name resolution. Test thoroughly.

Integration with Other IPA Components

Sudo Commands and Command Groups

Sudo commands (sudocmd-*) define individual commands. Sudo command groups (sudocmdgroup-*) organize commands into collections. Rules reference these objects rather than embedding command paths directly.

User and Group Management

Sudo rules reference user groups created through group-* commands. As users join or leave groups, their sudo privileges automatically adjust according to rules targeting those groups.

Host and Host Group Management

Sudo rules reference host groups created through hostgroup-* commands. As hosts join or leave host groups, the sudo rules active on those hosts automatically change.

HBAC Rules

Host-based access control must permit access before sudo rules apply. If HBAC blocks a user from accessing a host, sudo rules on that host never evaluate for that user. HBAC and sudo rules work together to control access.

External Users and Trust Relationships

Sudo rules can target external users from trusted Active Directory domains. Trust configuration (trust-* commands) must be functional for external user sudo rules to work.

SSSD Integration

SSSD on IPA clients retrieves sudo rules from IPA servers and caches them locally. SSSD handles rule evaluation and provides sudo with authorization decisions. SSSD configuration affects sudo rule refresh timing and offline operation.

Commands

Command Description

sudorule-add Create new Sudo Rule.

sudorule-add-allow-command Add commands and sudo command groups affected by Sudo Rule.

sudorule-add-deny-command Add commands and sudo command groups affected by Sudo Rule.

sudorule-add-host Add hosts and hostgroups affected by Sudo Rule.

sudorule-add-option Add an option to the Sudo Rule.

sudorule-add-runasgroup Add group for Sudo to execute as.

sudorule-add-runasuser Add users and groups for Sudo to execute as.

sudorule-add-user Add users and groups affected by Sudo Rule.

sudorule-del Delete Sudo Rule.

sudorule-disable Disable a Sudo Rule.

sudorule-enable Enable a Sudo Rule.

sudorule-find Search for Sudo Rule.

sudorule-mod Modify Sudo Rule.

sudorule-remove-allow-command Remove commands and sudo command groups affected by Sudo Rule.

sudorule-remove-deny-command Remove commands and sudo command groups affected by Sudo Rule.

sudorule-remove-host Remove hosts and hostgroups affected by Sudo Rule.

sudorule-remove-option Remove an option from Sudo Rule.

sudorule-remove-runasgroup Remove group for Sudo to execute as.

sudorule-remove-runasuser Remove users and groups for Sudo to execute as.

sudorule-remove-user Remove users and groups affected by Sudo Rule.

sudorule-show Display Sudo Rule.

sudorule-add

Usage: ipa [global-options] sudorule-add SUDORULE-NAME [options]

Create new Sudo Rule.

Arguments

Argument Required Description

SUDORULE-NAME yes Rule name

Options

Option Description

--desc DESC Description

--usercat USERCAT User category the rule applies to

--hostcat HOSTCAT Host category the rule applies to

--cmdcat CMDCAT Command category the rule applies to

--runasusercat RUNASUSERCAT RunAs User category the rule applies to

--runasgroupcat RUNASGROUPCAT RunAs Group category the rule applies to

Argument Required Description

SUDORULE-NAME yes Rule name

Options

SUDORULE-NAME yes Rule name

Options

Option Description

--all Retrieve and print all attributes from the server. Affects command output.

--raw Print entries as stored on the server. Only affects output format.

--no-members Suppress processing of membership attributes.

--users USERS users to add

`--groups GROUPS` groups to add

sudorule-add-user

Usage: ipa [global-options] sudorule-add-user SUDORULE-NAME [options]

Add users and groups affected by Sudo Rule.

Arguments

Argument Required Description

SUDORULE-NAME yes Rule name

Options

Option Description

--all Retrieve and print all attributes from the server. Affects command output.

--raw Print entries as stored on the server. Only affects output format.

--no-members Suppress processing of membership attributes.

Option Description

--sudorule-name SUDORULE-NAME Rule name

--desc DESC Description

--usercat USERCAT User category the rule applies to

--hostcat HOSTCAT Host category the rule applies to

--cmdcat CMDCAT Command category the rule applies to

--runasusercat RUNASUSERCAT RunAs User category the rule applies to

--runasgroupcat RUNASGROUPCAT RunAs Group category the rule applies to

--order ORDER integer to order the Sudo rules

--externaluser EXTERNALUSER External User the rule applies to (sudorule-find only)

--runasexternaluser RUNASEXTERNALUSER External User the commands can run as (sudorule-find only)

--runasexternalgroup RUNASEXTERNALGROUP External Group the commands can run as (sudorule-find only)

--timelimit TIMELIMIT Time limit of search in seconds (0 is unlimited)

--sizelimit SIZELIMIT Maximum number of entries returned (0 is unlimited)

--all Retrieve and print all attributes from the server. Affects command output.

--raw Print entries as stored on the server. Only affects output format.

`--pkey-only` Results should contain primary key attribute only (“sudorule-name”)

sudorule-mod

Usage: ipa [global-options] sudorule-mod SUDORULE-NAME [options]

Modify Sudo Rule.

Arguments

Argument Required Description

SUDORULE-NAME yes Rule name

Options

Option Description

--desc DESC Description

--usercat USERCAT User category the rule applies to

--hostcat HOSTCAT Host category the rule applies to

--cmdcat CMDCAT Command category the rule applies to

--runasusercat RUNASUSERCAT RunAs User category the rule applies to

--runasgroupcat RUNASGROUPCAT RunAs Group category the rule applies to

--order ORDER integer to order the Sudo rules

--externaluser EXTERNALUSER External User the rule applies to (sudorule-find only)

--runasexternaluser RUNASEXTERNALUSER External User the commands can run as (sudorule-find only)

Argument Required Description

SUDORULE-NAME yes Rule name

Options

SUDORULE-NAME yes Rule name

Options

Option Description

--all Retrieve and print all attributes from the server. Affects command output.

--raw Print entries as stored on the server. Only affects output format.

--no-members Suppress processing of membership attributes.

--users USERS users to remove

`--groups GROUPS` groups to remove

sudorule-remove-user

Usage: ipa [global-options] sudorule-remove-user SUDORULE-NAME [options]

Remove users and groups affected by Sudo Rule.

Arguments

Argument Required Description

SUDORULE-NAME yes Rule name

Options

Option Description

--all Retrieve and print all attributes from the server. Affects command output.

--raw Print entries as stored on the server. Only affects output format.

--no-members Suppress processing of membership attributes.

--users USERS users to remove

`--groups GROUPS` groups to remove

sudorule-show

Usage: ipa [global-options] sudorule-show SUDORULE-NAME [options]

Display Sudo Rule.

Arguments

Argument Required Description

SUDORULE-NAME yes Rule name

Options

Option Description

--rights Display the access rights of this entry (requires —all). See ipa man page for details.

--all Retrieve and print all attributes from the server. Affects command output.

--raw Print entries as stored on the server. Only affects output format.

Overview

Rule Components

Users and User Groups

Hosts and Host Groups

Allowed and Denied Commands

RunAs Users and Groups

Sudo Options

Rule Ordering

External User Support

Sudo Bind DN

Examples

Basic Rule Management

User Assignment

Host Assignment

Command Management

RunAs Configuration

Sudo Options

Rule Ordering

Rule State Management

External User Support (AD Integration)

Complete Rule Examples

Best Practices

Rule Design

Command Specification

Sudo Options

RunAs Configuration

Security Considerations

Operational Practices

External User Integration

Integration with Other IPA Components

Sudo Commands and Command Groups

User and Group Management

Host and Host Group Management

HBAC Rules

External Users and Trust Relationships

SSSD Integration

Commands

sudorule-show Display Sudo Rule.

sudorule-add

Arguments

Options

--no-members Suppress processing of membership attributes.

sudorule-add-allow-command

Arguments

Options

--sudocmdgroups SUDOCMDGROUPS sudo command groups to add

sudorule-add-deny-command

Arguments

Options

--sudocmdgroups SUDOCMDGROUPS sudo command groups to add

sudorule-add-host

Arguments

Options

--hostmask HOSTMASK host masks of allowed hosts

sudorule-add-option

Arguments

Options

--no-members Suppress processing of membership attributes.

sudorule-add-runasgroup

Arguments

Options

--groups GROUPS groups to add

sudorule-add-runasuser

Arguments

Options

--groups GROUPS groups to add

sudorule-add-user

Arguments

Options

--groups GROUPS groups to add

sudorule-del

Arguments

Options

sudorule-disable

Arguments

sudorule-enable

Arguments

sudorule-find

Arguments

`--no-members` Suppress processing of membership attributes.

`--sudocmdgroups SUDOCMDGROUPS` sudo command groups to add

`--sudocmdgroups SUDOCMDGROUPS` sudo command groups to add

`--hostmask HOSTMASK` host masks of allowed hosts

`--no-members` Suppress processing of membership attributes.

`--groups GROUPS` groups to add

`--groups GROUPS` groups to add

`--groups GROUPS` groups to add

`--pkey-only` Results should contain primary key attribute only (“sudorule-name”)

`--rename RENAME` Rename the sudo rule object

`--sudocmdgroups SUDOCMDGROUPS` sudo command groups to remove

`--sudocmdgroups SUDOCMDGROUPS` sudo command groups to remove

`--hostmask HOSTMASK` host masks of allowed hosts

`--no-members` Suppress processing of membership attributes.

`--groups GROUPS` groups to remove

`--groups GROUPS` groups to remove

`--groups GROUPS` groups to remove

`--no-members` Suppress processing of membership attributes.