— LiveStream

To install and configure sudo on IBM AIX, install the sudo .bff fileset with smitty installp, create an administrator group, grant that group rights in the sudoers file using visudo, and have users run privileged commands through sudo instead of logging in as root. This guide walks through the complete, accurate process on AIX, explains the configuration safely, and points you to the modern, supported way to do the same thing on current AIX 7.x.

Sharing the root password across a team is one of the oldest and most dangerous habits in Unix system administration. Installing sudo on AIX lets named users run exactly the commands they need with their own credentials, while every action is logged and attributable. That is better security, better auditing, and far easier offboarding when someone leaves the team.

Why use sudo on AIX instead of the root password

AIX does not ship a configured sudo by default the way many Linux distributions do, so administrators historically installed it manually. The payoff is significant:

• Accountability: sudo logs who ran what, when, and from where. A shared root login logs nothing useful.
• Least privilege: you can allow a user a single command (for example, restarting a service) without handing over full root.
• No password sharing: users authenticate with their own password, so you never have to rotate a shared root password after staff changes.
• Centralized policy: one sudoers file governs the whole server, and rules can be grouped by team.

Important version note: the original sudo 1.6.6.0 fileset referenced in many old AIX runbooks dates to the early 2000s and is long past end of life. It contains known security fixes that never made it back to that branch. Use it only if you are stuck supporting a frozen legacy box. On any AIX you actually maintain, install a current sudo (1.9.x) from the official AIX Toolbox for Open Source Software, covered near the end of this guide.

Step 1: Locate and install the sudo fileset

On AIX, native software ships as installp filesets packaged in .bff (Backup File Format) files. If you have a sudo .bff staged on the server, install it through SMIT. First change into the directory that holds the package:

1. Confirm the file is present and readable:
   1. cd /your/staging/path/sudo
   2. ls -l sudo*.bff
2. Launch the interactive install menu as root:
   1. smitty installp
3. Choose Install Software, then for the INPUT device / directory press F4 and select the current directory (.) or type the full path to the .bff.
4. For SOFTWARE to install, press F4 and select the sudo fileset, set PREVIEW only? to yes first to verify, then re-run with COMMIT software updates? set as appropriate and ACCEPT new license agreements? set to yes.
5. Press Enter to install and wait for the OK status.

If you prefer the command line over the SMIT menus, the equivalent non-interactive install is:

installp -acgYXd . sudo

Here -a applies, -c commits, -g auto-includes prerequisites, -Y accepts licenses, -X expands the filesystem if needed, and -d . reads from the current directory. After it finishes, verify the fileset is registered:

lslpp -l | grep -i sudo

You should see the sudo fileset listed in the COMMITTED state. The binaries from these classic AIX builds install under /usr/local: the user command at /usr/local/bin/sudo and the editor at /usr/local/sbin/visudo. Confirm the binary runs:

/usr/local/bin/sudo -V

Step 2: Create an administrators group

Rather than naming individual users in the sudoers file, create a group and grant rights to the group. Adding or removing an admin then becomes a single group-membership change. Create a group called sysadmin:

1. Create the group (the -A flag lets the group administer itself if you want that):
   1. mkgroup sysadmin
2. Add an existing user and make sysadmin their primary group, or simply add it as a secondary group, which is usually safer:
   1. Secondary (recommended): chuser groups=staff,sysadmin sxia
   2. Primary (only if you really need it): chuser pgrp=sysadmin sxia
3. Verify membership:
   1. lsgroup sysadmin
   2. id sxia

A caution on primary groups: the old runbook told users to set sysadmin as the primary group. That works, but changing a user's primary group also changes the ownership context of files they create and can break application accounts. Adding sysadmin as a secondary group via chuser groups=... gives the same sudo rights with far less risk. The user may need to log out and back in (or run newgrp) for the new group to take effect.

Step 3: Edit the sudoers file safely with visudo

Never edit /etc/sudoers (or the AIX path /usr/local/etc/sudoers for the classic build) with a plain text editor. Always use visudo. It locks the file against concurrent edits and, critically, runs a syntax check before saving. A broken sudoers file can lock everyone out of root, so this safety net matters. As root, run:

/usr/local/sbin/visudo

Find the user privilege specification section and add a line granting the sysadmin group full rights. A clean, minimal policy looks like this:

1. The default root rule (leave it as is):
   1. root ALL=(ALL) ALL
2. Allow everyone in the sysadmin group to run any command as any user (note the leading % marks it as a group):
   1. %sysadmin ALL=(ALL) ALL

The four fields read as: who the rule applies to, on which hosts (ALL), as which target users (the part in parentheses), and which commands. So %sysadmin ALL=(ALL) ALL means "members of sysadmin, on all hosts, may run all commands as any user."

When you exit the editor, visudo validates the file. If you see a parse error, choose to re-edit rather than save the broken file. After saving, you can confirm syntax independently with:

/usr/local/sbin/visudo -c

Tightening the policy: least privilege examples

Granting a whole group full root is convenient but broad. The real power of sudo is restricting it. Here are accurate, working patterns you can drop into visudo:

Use NOPASSWD sparingly and only for tightly scoped commands. A NOPASSWD: ALL rule effectively turns sudo back into passwordless root, which defeats much of the point.

For repeated patterns, sudoers supports aliases so your policy stays readable:

1. Define a command alias: Cmnd_Alias SERVICES = /usr/bin/startsrc, /usr/bin/stopsrc, /usr/bin/refresh
2. Use it in a rule: %appops ALL=(root) SERVICES

Step 4: Use sudo as a regular user

Now log in with the user account you added to sysadmin and elevate. The classic way to get a full root shell is to run a login shell as root through sudo:

1. Log in as your own user (for example sxia).
2. Request a root login shell:
   1. /usr/local/bin/sudo su -
3. Enter your own password when prompted (not root's). A typical session looks like:
   1. sxia@dmspar01[/home/sxia]# /usr/local/bin/sudo su -
   2. Password:
   3. root@dmspar01[/]#

A cleaner, more modern habit is to run individual commands with sudo rather than opening a long-lived root shell, because that keeps the audit log meaningful:

1. Run a single privileged command: sudo lsvg -o
2. Open an interactive root shell only when you truly need one: sudo -i
3. Run a command as a specific non-root user: sudo -u oracle sqlplus

If /usr/local/bin is not on your PATH, either type the full path or add it. To call sudo without the full path every time, append to your profile: export PATH=$PATH:/usr/local/bin.

Common pitfalls when configuring sudo on AIX

Most sudo problems on AIX come from a handful of recurring mistakes. Watch for these:

• Editing sudoers directly. A single typo in /etc/sudoers can break sudo for everyone. Always go through visudo so the syntax check protects you.
• Forgetting the % on group rules. sysadmin ALL=(ALL) ALL tries to match a user named sysadmin; %sysadmin matches the group. This is the single most common sudoers error.
• Group membership not active. After chuser, the user must start a fresh login session (or use newgrp) before the new group is recognized.
• Wrong sudoers path. The classic /usr/local build keeps its sudoers under /usr/local/etc/sudoers, while Toolbox RPM builds use /etc/sudoers and /etc/sudoers.d/. Edit the one your build actually reads — check with sudo -V | grep -i sudoers.
• Using full paths in restricted rules carelessly. If a rule names /usr/bin/foo but the binary lives at /usr/sbin/foo, the command is denied. Verify each path with which.
• Relying on EOL sudo 1.6.x. It has unpatched CVEs. Treat the legacy install as a stopgap and plan the upgrade.

Step 5: Verify the configuration works

Confirm the whole chain end to end before you trust it in production:

1. Check the fileset installed: lslpp -l | grep -i sudo
2. Validate sudoers syntax: /usr/local/sbin/visudo -c
3. As the target user, list their granted rights without running anything: sudo -l
4. Run a harmless privileged test command, for example: sudo id — it should return uid=0(root).
5. Confirm logging. Sudo events are recorded via syslog; check your auth log (commonly /var/adm/messages or wherever your /etc/syslog.conf routes auth facility messages) for a line showing the user, the command, and the working directory.

If sudo -l shows the expected rules and sudo id returns root, your configuration is correct.

The modern way: sudo from the AIX Toolbox

On supported AIX 7.1, 7.2, and 7.3 systems, do not chase old .bff files. IBM distributes a current, maintained sudo through the AIX Toolbox for Open Source Software as an RPM, installed with dnf (the Toolbox now uses dnf in place of the older yum):

1. Install or bootstrap the Toolbox dnf using IBM's published installer, then run: dnf install sudo
2. This places sudo at /opt/freeware/bin/sudo (often symlinked into /usr/bin) and uses /etc/sudoers with an /etc/sudoers.d/ drop-in directory.
3. Edit policy the same safe way: visudo, or drop per-team files into /etc/sudoers.d/ (each validated by visudo -c -f).
4. Keep it patched: dnf update sudo as security fixes are released.

The configuration concepts in this guide — groups, the four-field rule syntax, visudo, least privilege, and verification — are identical between the legacy and Toolbox builds. Only the install command and file paths differ.

Key Takeaways

• Install sudo on AIX with smitty installp (or installp -acgYXd . sudo) and verify with lslpp -l | grep -i sudo.
• Grant rights to a group, not individuals: create sysadmin with mkgroup, add users with chuser, and use the %sysadmin group rule in sudoers.
• Always edit the policy with visudo so its built-in syntax check prevents a lockout.
• Favor least-privilege rules and run individual commands with sudo rather than living in a root shell, so the audit log stays meaningful.
• Legacy sudo 1.6.6.0 is end of life — on maintained AIX, install the current sudo from the AIX Toolbox via dnf install sudo and keep it patched.

Frequently Asked Questions

Where is the sudoers file located on AIX?

It depends on the build. The classic /usr/local install keeps it at /usr/local/etc/sudoers, while the AIX Toolbox RPM uses /etc/sudoers with drop-ins in /etc/sudoers.d/. Run sudo -V | grep -i sudoers to see the exact path your binary reads, and always edit it with visudo.

Why does sudo ask for a password, and whose password is it?

By default sudo prompts for the invoking user's own password, not root's, then caches it for a few minutes. This proves the person at the keyboard is really that user. You can disable the prompt for specific, tightly scoped commands with a NOPASSWD: rule, but avoid NOPASSWD: ALL because it undermines the security sudo provides.

How do I let a user run only one command with sudo on AIX?

Add a rule that names the full command path, for example jdoe ALL=(root) /usr/bin/stopsrc -s sshd, /usr/bin/startsrc -s sshd. The user can then restart that service but nothing else. Verify the binary's exact path with which first, because a wrong path causes the command to be denied.

Is the old sudo 1.6.6.0 fileset safe to keep using?

Only on a frozen legacy system you cannot change. That branch is many years past end of life and carries unpatched vulnerabilities. On any AIX you actively maintain, install the current sudo (1.9.x) from the AIX Toolbox with dnf install sudo and apply updates regularly.

If this walkthrough helped, subscribe to @explorenystream on YouTube for more practical AIX and Unix system administration guides.