AWS + Linux Combo — Part 4: Linux File Permissions & Users on EC2
One of the things that confuses people when they first start working with Linux servers is permissions. On Windows, you mostly click "Allow" or "Deny" and things work. On Linux, permissions are more explicit and more powerful. Understanding them is essential for running a secure cloud server on AWS.
Why Permissions Matter on EC2
Your EC2 instance is accessible over the internet. That means if a file has the wrong permissions, an attacker who gains access could read it. If a directory has wrong permissions, a script could overwrite critical files. Permissions are the first layer of defense on any Linux server. Cloud security starts with getting them right.
Linux Permission Model
Every file and directory in Linux has three types of permissions — read, write, and execute — and three categories of users they apply to: owner, group, and others (everyone else).
ls -la
# Output looks like:
# -rwxr-xr-- 1 ec2-user ec2-user 1234 Mar 17 10:00 script.sh
# drwxr-xr-x 2 ec2-user ec2-user 4096 Mar 17 09:00 mydir/Breaking down -rwxr-xr--: the first character is the file type (- for file, d for directory). Then come three groups of three characters each: owner permissions (rwx), group permissions (r-x), and others permissions (r--).
r= read (4)w= write (2)x= execute (1)-= no permission (0)
Changing Permissions with chmod
chmod changes file permissions. You can use symbolic or numeric (octal) notation:
# Give owner full permissions, group read+execute, others nothing
chmod 750 script.sh
# Make file readable by everyone
chmod 644 readme.txt
# Make a script executable by owner only
chmod 700 myscript.sh
# Symbolic way: add execute for owner
chmod u+x script.sh
# Remove write for others
chmod o-w file.txt
# Apply permissions recursively to a directory
chmod -R 755 /var/www/html/Changing Ownership with chown
chown changes who owns a file or directory:
# Change file owner to ec2-user
sudo chown ec2-user myfile.txt
# Change both owner and group
sudo chown ec2-user:ec2-user myfile.txt
# Change owner recursively for a directory
sudo chown -R ec2-user:ec2-user /var/www/User Management on EC2
Your EC2 instance starts with the ec2-user account. In real-world scenarios, you often need to create additional users — for example, for different team members or for running applications under dedicated service accounts:
# Create a new user
sudo useradd devuser
# Set a password
sudo passwd devuser
# Create user with home directory and shell
sudo useradd -m -s /bin/bash appuser
# Add user to a group
sudo usermod -aG wheel devuser # wheel = sudo group on Amazon Linux
sudo usermod -aG sudo devuser # sudo group on Ubuntu
# View all users
cat /etc/passwd
# Delete a user
sudo userdel -r devuser # -r removes home directory tooUnderstanding sudo
The sudo command lets you run commands with root (administrator) privileges. On EC2, the ec2-user account has full sudo access without a password — AWS configured this intentionally for convenience. In production environments, you would restrict this more tightly.
# Run a command as root
sudo systemctl restart nginx
# Open a root shell (use carefully)
sudo su -
# Run a command as a different user
sudo -u appuser python3 app.py
# Check sudo privileges
sudo -lSSH Key Management for Multiple Users
When you have multiple users on an EC2 instance, each user who needs SSH access requires their own authorized_keys file. Here is how to set it up:
# Switch to the new user
sudo su - devuser
# Create .ssh directory
mkdir ~/.ssh
chmod 700 ~/.ssh
# Create authorized_keys file and add their public key
nano ~/.ssh/authorized_keys
# Paste their public key here, save and exit
# Set correct permissions
chmod 600 ~/.ssh/authorized_keysImportant Security Practices
Running a Linux server on AWS means it is exposed to the internet. Here are key security habits to develop from the start. Never run your application as root — create a dedicated user for it. Keep file permissions as restrictive as possible. Only open ports in your Security Group that are actually needed. Regularly check /var/log/auth.log or /var/log/secure for failed login attempts, which indicate scanning or brute-force activity. Disable password authentication for SSH and use key pairs only — AWS does this by default, and you should keep it that way.
In Part 5, we will install Nginx on our EC2 instance and serve our first web page from a Linux server in the cloud.
Sudo and Privilege Escalation on EC2
On EC2 instances, the default user (ubuntu on Ubuntu AMIs, ec2-user on Amazon Linux) can run commands as root using sudo without a password — this is configured in /etc/sudoers. This is convenient for administration but means protecting the instance's SSH access is critical. Never create additional users with unrestricted sudo access unless necessary. For application deployments, create a dedicated service account with only the permissions needed: sudo useradd --system --no-create-home appuser. Run the application as this service user rather than as ubuntu or root. This follows the principle of least privilege — limiting the damage if the application is compromised.
Managing Multiple Users on EC2 for Teams
When multiple team members need access to an EC2 instance, resist the temptation to share a single SSH key or user account. Instead, create individual user accounts for each team member and add their public SSH keys. This provides individual accountability through audit logs and allows access to be revoked for specific individuals without disrupting others. A cleaner approach for larger teams is to use AWS Systems Manager Session Manager — it provides browser-based shell access to EC2 instances without any SSH keys, using IAM credentials for authentication and automatically logging all session activity to CloudWatch.
Practice Exercise
On your EC2 instance, create a new user account: sudo useradd -m -s /bin/bash newuser. Create the .ssh directory for the new user, add an authorized key (use your existing public key for testing), and set proper permissions (chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys). Test SSH access as the new user. Then use sudo visudo to grant the new user specific sudo permissions for a single command rather than full sudo access, and verify the restriction works.