Open source security in 2026: How to protect the supply chain and control access using usermod?

Linux security is not just about trusted packages, but primarily about rigorous control of local permissions. Recent Canonical analyses of the open source supply chain show how easy it is to stumble. In this post, we go back to basics and explain how to efficiently manage users using the usermod command.

New challenges in the open source supply chain in 2026

Canonical recently published analyses regarding supply chain security in open source software. As attacks on IT infrastructure become an everyday occurrence, the security of code downloaded from external repositories is essential. Developers and administrators must accept the fact that even stable distributions can be targets of upstream attacks. Without proper verification and control, the risk is simply too high.

However, securing the code itself is only half the battle. What happens directly on the server is equally important. Even the best-vetted application will fail if the local permission configuration leaves the door open for intruders. When deploying enterprise solutions – for example, choosing a stable Ubuntu Server in 2026 – one must remember the Principle of Least Privilege. This entire process starts with precise management of users and groups.

Back to basics: Why does local access control matter?

Most security incidents that do not result directly from vulnerabilities in application code have their source in common configuration errors. Overly broad permissions, forgotten accounts with administrator access, or incorrectly assigned groups are classic examples.

In Linux, the primary tool for modifying user accounts is the usermod command. Although most administrators learn it at the beginning of their professional journey, they rarely use the full potential of this command. We usually limit ourselves to one, most popular parameter. Meanwhile, a good knowledge of usermod allows you to precisely control access and minimize the risk of privilege escalation. Such actions perfectly complement other protective mechanisms, such as the new limitations in the Linux 7.3 kernel and AF_ALG, which tighten the cryptographic layer of the system.

How does the usermod command work? A practical guide

The usermod command modifies user account configuration files (such as /etc/passwd or /etc/group). To use it, you need root privileges or to invoke the command via sudo.

Changing username, group, and UID

This is one of the most common administrative tasks.

• Changing a username (login): The -l parameter is used for this.

  sudo usermod -l nowa_nazwa stara_nazwa

  Changing logins, however, will not change the name of the home directory. To move its content and change the path, combine the -d and -m parameters.
• Changing a user's primary group: The -g parameter is used for this.

  sudo usermod -g nowa_grupa_glowna nazwa_uzytkownika

• Changing a unique UID identifier: The -u parameter is used for this.

  sudo usermod -u 1500 nazwa_uzytkownika

  After this operation, the system will automatically update file ownership in the home directory. Remember, however, that files located outside of it (e.g., in shared directories) will retain the old UID and will need to be corrected manually using chown.

Managing supplementary groups: The key difference between -a and -G

This is where it is easiest to make a mistake that could result in accidentally revoking permissions (e.g., access to sudo). Usually, we simply want to add a user to a new supplementary group while keeping the existing ones. The combination of the -a (append) and -G (groups) parameters is used for this:

sudo usermod -aG nazwa_grupy nazwa_uzytkownika

Note: If you use the -G parameter without the -a flag, you will overwrite all of the user's existing supplementary groups. This way, you can instantly cut someone off from critical resources or administrator privileges.

In some systems, the -A parameter is used to remove a user from a group, although it is safer and more common to use the dedicated gpasswd -d command. It is always worth checking the documentation of a specific distribution before performing such changes in production.

Changing the user's default shell

For system accounts that should not allow interactive login, it is good practice to set a blocking shell (e.g., /usr/sbin/nologin or /bin/false). For regular users needing a terminal, we set the standard /bin/bash or /bin/zsh. The -s parameter is used for this:

sudo usermod -s /bin/bash nazwa_uzytkownika

Limitations and pitfalls when using usermod

Although usermod is a great tool, it has its limitations that you must remember during daily work:

1. Logged-in users: You cannot change a username (the -l parameter) if their processes are running in the background or if they are logged in. Before modification, you must ensure that the session has been closed (e.g., using killall -u nazwa_uzytkownika).
2. Consistency of files outside the home directory: Changing the UID (-u) automatically updates permissions in the home directory, but temporary or shared files in other locations (e.g., in /var or /opt) will retain the old UID. This can later cause difficult-to-diagnose access problems.

Best practices for permission management in 2026

Mastering basic commands is not enough. To effectively protect systems against external and internal threats, it is worth implementing a few good habits:

• Principle of Least Privilege: Users should only belong to groups necessary for their work. Avoid mass adding accounts to the wheel or sudo group just in case.
• Precise sudoers configuration: Instead of handing out full administrator privileges, configure the /etc/sudoers file to allow running only specific commands.
• Regular account audits: Systematically check the list of active users – especially those with a UID of 0 (other than root) and system accounts that should have a locked shell.
• Automation and centralization: With a larger number of machines, manually typing usermod on every server is pointless. In such situations, central identity management (IdM) and automation tools like Ansible or Puppet become the standard.

Summary

Securing Linux systems requires a multi-faceted approach. On one hand, we must track security analyses and ensure the integrity of the software supply chain. On the other – we must not forget the basics, i.e., correct configuration of local permissions. Conscious and precise use of the usermod command is one of the first steps toward building a stable and secure server environment.

Sources

• https://www.tecmint.com/usermod-command-examples-linux/
• https://ubuntu.com//blog/open-source-security-research
• https://www.youtube.com/watch?v=aAg9iDh9_BQ