Password Policies and User Privileges

Password aging is a set of rules that force users to change their passwords after a certain amount of time. On a Linux system, every user account has an entry in the /etc/shadow file, which stores the encrypted password and several date-related fields. The chage command (short for 'change age') lets an administrator view or modify these fields. The key parameters are: -M sets the maximum number of days a password is valid (e.g., -M 90 means the password expires after 90 days), -m sets the minimum number of days before a user can change it again (to stop users from cycling back to the same password too fast), -W sets the number of days before expiry that a warning is shown, and -I sets the number of days after expiry that the account is locked if the password is not changed. For example, sudo chage -M 90 -m 7 -W 14 -I 30 username forces the user to change their password at least every 90 days, wait 7 days before changing it again, see a warning 14 days before it expires, and get locked out after 30 days of inactivity. This replaces the old method of doing nothing—leaving passwords unchanged for years, which is a huge security risk because leaked passwords from other sites can be used to break in.

When you run chage -l username, you see the current aging information: Last password change, Password expires, Password inactive, Account expires, and Minimum number of days between password changes. Aging policies are often set system-wide in /etc/login.defs with variables like PASS_MAX_DAYS, PASS_MIN_DAYS, and PASS_WARN_AGE. These defaults apply to all new users unless overridden per user. For existing users, you must run chage or edit their shadow entry manually.

Now, user privileges. Every action on a Linux system is controlled by permissions. Files and directories have three permission sets: owner (u), group (g), and others (o). These are read (r=4), write (w=2), and execute (x=1). For example, -rwxr-xr-- means the owner can read, write, and execute; the group can read and execute; everyone else can only read. This is called discretionary access control (DAC) because the file owner decides who gets access. But managing privileges for dozens of users on a server requires more control.

The sudo command lets authorised users run commands as another user (usually root). Sudo privileges are defined in the /etc/sudoers file, which should be edited with visudo to prevent syntax errors. A typical entry is username ALL=(ALL:ALL) ALL, which gives that user full root access. More granular entries like username ALL=(ALL:ALL) /usr/bin/apt, /usr/bin/systemctl only allow specific commands. Groups can be used: %admin ALL=(ALL:ALL) ALL gives all members of the admin group sudo access.

User groups simplify permission management. Instead of setting privileges for each user individually, you create a group (e.g., webdev), add users to it with usermod -aG groupname username, then set file permissions for the group. For example, chown :webdev /var/www changes the group ownership of the directory, and chmod 2775 /var/www gives the group write access (the 2 sets the setgid bit, so new files in that directory inherit the group). This approach scales: when a user leaves, you remove them from the group instead of hunting down every file they owned.

Password aging and privilege management together form the basis of system hardening. Without aging, a stolen password gives indefinite access. Without privilege control, a compromised user can delete critical files or install malware. The LFCS exam tests your ability to set these policies using command-line tools like chage, usermod, groupadd, gpasswd, and the sudoers configuration.

You are the sole IT administrator for a small tech startup with 50 employees. The company uses a single Linux server to host its internal web application, customer database, and source code repository. Your manager asks you to 'secure the system' because a competitor recently had a data breach from an old password. Here is what you actually do, step by step.

First, you audit current user accounts. You run cat /etc/passwd | grep /home to list real users, then chage -l username for each one. You discover that most employees have never changed their passwords—some accounts are two years old. The CEO’s password is set to never expire (chage shows Password expires : never). You run sudo chage -M 90 -m 7 -W 14 -I 30 *? No—that wildcard doesn't work. Instead, you write a small loop script or use a for loop in bash: for user in $(ls /home); do sudo chage -M 90 -m 7 -W 14 -I 30 $user; done. This ensures everyone must change their password within 90 days, with a 7-day minimum between changes.

Next, you set system-wide defaults by editing /etc/login.defs. You change PASS_MAX_DAYS to 90, PASS_MIN_DAYS to 7, and PASS_WARN_AGE to 14. Adding ENCRYPT_METHOD SHA512 ensures passwords are hashed securely (SHA-512 is a one-way cryptographic function). You test the policy by creating a new user: sudo useradd -m -s /bin/bash testuser && sudo passwd testuser. Then chage -l testuser shows the defaults applied.

Now for privileges. The web application team needs write access to /var/www/html and the database dump directory /backups/db. You create a group called webdev: sudo groupadd webdev. Then you add the five developers: sudo usermod -aG webdev alice, sudo usermod -aG webdev bob, and so on. You set the directory permissions: sudo chown -R root:webdev /var/www/html and sudo chmod -R 2775 /var/www/html. The 2 sets the setgid bit so new files inherit the group. For backups, you do the same with /backups/db.

The junior sysadmin needs to restart the web server and view logs but should not have full root. You add a sudoers entry: %webdev ALL=(ALL:ALL) /usr/bin/systemctl restart apache2, /usr/bin/journalctl—this lets any member of webdev run only these two commands as root. You use visudo to edit safely. You also set up a sudo log via Defaults logfile=/var/log/sudo.log in /etc/sudoers so you can track who ran which command.

Finally, you automate user expiry for contractors. You create a user for a freelancer with an account expiry: sudo useradd -e 2025-12-31 -m freelancer. The -e date sets the account to expire on that day. After the project ends, the account locks automatically. You also set sudo chage -E 2025-12-31 freelancer as a backup.

This whole process—auditing, setting password aging, creating groups, assigning privileges, and automating expiry—is exactly what a real IT professional does. It prevents unauthorised access, contains damage if an account is compromised, and simplifies audits because you can show clear policies and logs. The LFCS exam expects you to know these exact commands and their options.