Mobile App Now Available

Master Interviews
Anywhere, Anytime

Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.

Get it on

Google Play

4.9/5 Rating on Store

Subject page

Linux & Shell Scripting · Question Set

User & Permission Management – Linux & Shell Scripting interview questions

User & Permission Management interview questions for placements and exams.

Subject: Linux & Shell ScriptingDifficulty: Mixed16 questions in this set

Set overview

Questions

Included in this set

Subject

Linux & Shell Scripting

Explore more sets

Difficulty

Mixed

Level of this set

Linux & Shell Scripting – User & Permission Management questions (16)

Go through each question and its explanation. Use this set as a focused practice pack for Linux & Shell Scripting.

Back to Linux & Shell Scripting subject page

1. Explain the complete process of creating, modifying, and deleting user accounts. Include commands, files involved, and best practices.

Difficulty: MediumType: SubjectiveTopic: User Management

Create user with useradd: useradd -m -s /bin/bash -G sudo,docker -c 'Full Name' username creates user with home directory (-m), bash shell (-s), adds to groups (-G), and sets comment (-c). Set password immediately with passwd username for security. Verify creation with id username showing UID, GID, and groups. Modify users with usermod: usermod -aG newgroup username adds to supplementary group (append, doesn't remove existing), usermod -s /bin/zsh username changes shell, usermod -L username locks account (prevents login), usermod -U username unlocks. Change primary group with usermod -g groupname username. Rename user with usermod -l newname oldname, but manually rename home directory with mv /home/oldname /home/newname. Delete users with userdel: userdel username removes user but leaves home directory and files, userdel -r username removes user and home directory (use caution - data loss). Check for running processes with ps -u username before deletion. Find files owned by deleted users with find / -uid UID -ls, then reassign ownership or delete as appropriate. Best practices: use consistent UID ranges (1000+ for regular users), enforce strong passwords with PAM configuration, lock accounts rather than deleting for users who leave (preserves file ownership), audit user access regularly, document account purposes especially for service accounts, set account expiration dates with chage for temporary accounts, and maintain user provisioning/deprovisioning procedures. Security considerations: disable root SSH login (PermitRootLogin no in sshd_config), require key-based authentication, set password policies (minimum length, complexity, expiration), monitor for unauthorized accounts in /etc/passwd, and regularly review sudo access. Automate user management with configuration management tools like Ansible or Puppet for consistency across multiple systems.

Continue your preparation

For complete preparation, combine this set with full subject-wise practice for Linux & Shell Scripting. You can also explore other subjects and sets from the links below.

Quick navigation:Linux & Shell Scripting subject page•All subjects

6. Explain umask in Linux. How does it work and how do you calculate default permissions for new files and directories?

Difficulty: HardType: SubjectiveTopic: File Permissions

Umask (user file creation mask) defines default permissions for newly created files and directories by specifying which permission bits to remove from the default permissions. Default permissions before umask are 666 (rw-rw-rw-) for files and 777 (rwxrwxrwx) for directories. Umask subtracts permissions from these defaults. Calculation: umask 0022 (common default) removes write permission for group and others. For files: 666 - 022 = 644 (rw-r--r--). For directories: 777 - 022 = 755 (rwxr-xr-x). Note that umask 0002 would give 664 for files and 775 for directories, allowing group write access. More restrictive umask 0077 gives 600 files and 700 directories (owner-only access). Set umask temporarily with umask 0022 command (affects current shell session). Set permanently in ~/.bashrc, ~/.profile, or /etc/profile for system-wide defaults. View current umask with umask command showing octal value, or umask -S showing symbolic format (u=rwx,g=rx,o=rx). Different umask for different users by setting in individual profiles. Common umask values: 0022 (files 644, dirs 755) - standard for most users, allows others to read but not modify; 0002 (files 664, dirs 775) - collaborative environments where group members share write access; 0077 (files 600, dirs 700) - restrictive, only owner has access, used for sensitive data; 0000 (files 666, dirs 777) - fully permissive, rarely appropriate. Security considerations: more restrictive umask is more secure but less convenient for collaboration. Choose based on environment: single-user workstations can use 0022, shared servers might need 0002 for group collaboration, security-sensitive systems should use 0077. Remember umask affects default permissions - can always change permissions after creation with chmod. Understanding umask prevents permission issues with newly created files.

10. How do you troubleshoot permission denied errors? Describe the systematic approach to identifying and fixing permission issues.

Difficulty: HardType: SubjectiveTopic: File Permissions

Start by identifying what operation failed and what user performed it. Check file permissions with ls -l filename, showing owner, group, and permissions. Check user's identity and groups with id username or whoami and groups. Match user's groups against file's group to understand access level. Check if special permissions (setuid, setgid, sticky bit) are involved with ls -l. Verify directory permissions in the path. To access a file, you need execute permission on all parent directories. Example: accessing /home/user/data/file.txt requires execute on /, /home, /home/user, and /home/user/data, plus read on file.txt. Use namei -l /path/to/file to show permissions for entire path, identifying where access fails. Check ACLs with getfacl filename if '+' appears in ls -l output. ACLs might grant or deny access beyond standard permissions. Check SELinux context with ls -Z filename if SELinux is enabled - wrong context causes permission denied even with correct file permissions. Verify with getenforce showing Enforcing/Permissive/Disabled. Check audit logs at /var/log/audit/audit.log for SELinux denials. Common fixes: chmod to adjust file permissions, chown to change ownership, chgrp to change group, usermod -aG to add user to required group (requires logout/login), setfacl to add specific user/group access, chcon or restorecon to fix SELinux contexts. For directories, ensure execute permission. For shared access, consider creating shared group, setting group ownership, and using 2770 permissions (rwxrws--- with setgid). Preventive measures: use umask to set default permissions for new files (e.g., umask 0022 for 644 files, 755 directories), document permission schemes, establish ownership standards for shared directories, use group-based access control over ACLs when possible for simplicity, and test permission changes before applying to production. Understanding permission inheritance and defaults prevents future issues.

11. Explain the /etc/sudoers file structure and how to configure granular sudo access. Include examples of different sudo configurations.

Difficulty: HardType: SubjectiveTopic: Sudoers Config

The /etc/sudoers file controls sudo access and must be edited with visudo command (never edit directly - visudo validates syntax preventing lockout). Basic syntax: user host=(runas_user:runas_group) commands. Example: john ALL=(ALL:ALL) ALL gives john full sudo access on all hosts, running any command as any user/group. User specifications: root ALL=(ALL:ALL) ALL (root has full access), %sudo ALL=(ALL:ALL) ALL (group specification with % prefix - all sudo group members have full access), john ALL=(ALL) NOPASSWD: ALL (john doesn't need password for sudo), jane ALL=/usr/bin/systemctl,/usr/bin/service (jane can only run specific commands with sudo). Command aliases simplify management: Cmnd_Alias SERVICES = /usr/bin/systemctl, /usr/bin/service then john ALL=(root) SERVICES allows john to run service management commands. User aliases: User_Alias ADMINS = john, jane, bob then ADMINS ALL=(ALL) ALL gives multiple users access. Host aliases for multi-host environments: Host_Alias WEBSERVERS = web1, web2. Advanced configurations: john ALL=(apache) NOPASSWD: /usr/bin/systemctl restart httpd allows john to restart apache as apache user without password, useful for deployment scripts. Restrict to specific hosts: john WEBSERVERS=(ALL) ALL only on webservers. Deny commands: john ALL=(ALL) ALL, !/usr/bin/rm -rf / (whitelist with blacklist exceptions, though blacklisting is generally ineffective). Best practices: use visudo always (syntax checking), prefer groups over individual users (easier management), use NOPASSWD sparingly (security risk), be specific with command paths (prevents PATH manipulation), validate command arguments where possible, include sudoers.d directory (includedir /etc/sudoers.d) for modular configuration, test sudo rules thoroughly, and document why each rule exists. Regular audits prevent permission creep.

12. What are service accounts and how should they be managed? Explain best practices for creating and securing service accounts.

Difficulty: MediumType: SubjectiveTopic: Privilege Escalation

Service accounts are special user accounts for running services, applications, or automated processes rather than for human login. They typically have /sbin/nologin or /bin/false as shell preventing interactive login, and UIDs in system range (often 1-999). Examples: www-data for web servers, mysql for MySQL database, nobody for unprivileged operations. Create service accounts with useradd -r -s /sbin/nologin -c 'Service Description' servicename. The -r flag creates system account with UID in system range. Assign minimal necessary permissions following least privilege principle - service accounts should only access files/directories needed for their function. Use dedicated groups for service account permissions rather than giving broad access. Security best practices: disable password login (service accounts shouldn't have passwords), use SSH keys or other authentication mechanisms if remote access needed, restrict sudo access (service accounts rarely need sudo), set proper file ownership (service should own its files), use SELinux or AppArmor to confine service processes, regularly audit service account permissions, document each service account's purpose, and remove unused service accounts. For containerized environments, avoid root in containers - use USER directive in Dockerfile to run as non-root service account. For Kubernetes, use ServiceAccount resources with RBAC for permissions. For cloud platforms, use IAM roles instead of long-lived credentials. Never share service accounts across different services - each service should have dedicated account for auditing and isolation. Monitoring: track service account activity in logs, alert on unexpected access patterns (service accounts have predictable behavior), audit file access, and regularly review permissions. Use configuration management tools (Ansible, Puppet) to ensure consistent service account setup across systems. Document which human administrator is responsible for each service account.

13. Explain setuid and setgid special permissions. Provide examples of when they're necessary and security implications.

Difficulty: HardType: SubjectiveTopic: Privilege Escalation

Setuid (Set User ID) on executable files causes the file to execute with owner's privileges instead of the executor's. When setuid bit is set on file owned by root, any user running it executes with root privileges. Indicated by 's' in owner execute position (rwsr-xr-x). Set with chmod u+s file or chmod 4755 file (4 in leading digit). Classic example: /usr/bin/passwd has setuid bit and is owned by root. Regular users need to modify /etc/shadow (root-only file) to change their password. Setuid allows passwd to run as root, modify shadow file, but only accepts user's own password change. Other examples: sudo, su, ping (needs raw sockets requiring root), mount (some implementations). Setgid (Set Group ID) on executables causes execution with file's group privileges. Indicated by 's' in group execute position (rwxr-sr-x). Set with chmod g+s file or chmod 2755 file. On directories, setgid causes new files to inherit directory's group instead of creator's primary group, useful for shared directories where all files should be group-owned. Setgid directory example: mkdir /shared/project && chgrp developers /shared/project && chmod 2775 /shared/project creates shared directory where all files inherit developers group ownership, allowing team collaboration. Without setgid, files would have creator's primary group, potentially breaking access for team members. Security implications: setuid/setgid are major security risks if misused - they're common attack vectors. Audit setuid files regularly: find / -perm -4000 -type f 2>/dev/null lists all setuid files. Review necessity, ensure secure coding (no shell command injection, buffer overflows, path manipulation). Remove setuid from unnecessary files. Avoid creating custom setuid programs unless absolutely necessary and thoroughly security-reviewed. Use capabilities instead of setuid where possible (more granular privileges). SELinux can restrict setuid operations. Understanding these permissions is critical for security hardening.

14. What are best practices for managing a multi-user Linux system? Discuss user isolation, resource limits, and security hardening.

Difficulty: HardType: SubjectiveTopic: Privilege Escalation

User isolation: each user should have separate home directory (mode 700) preventing other users from accessing their files. Use private groups (one group per user) as primary group. Avoid shared accounts - each person should have individual account for accountability. Separate service accounts from user accounts. Use PAM to restrict which users can login, which services they can use, and from where (IP restrictions). Resource limits with ulimit or /etc/security/limits.conf prevent users from consuming excessive resources. Set limits on: max processes (nproc), max open files (nofile), max file size (fsize), max CPU time (cpu), max memory (as, rss). Example: username hard nproc 100 limits user to 100 processes. Use cgroups for more sophisticated resource management including CPU shares, memory limits, and I/O priorities. Password policies: enforce strong passwords with pam_pwquality, set maximum password age with chage, implement account lockout after failed attempts with pam_faillock, require password on sudo unless specific exceptions, disable root login over SSH, and use key-based authentication where possible. Regular password audits detect weak passwords before attackers do. Access control: principle of least privilege - grant minimum necessary permissions. Use groups for permission management rather than ACLs when possible. Regularly audit user accounts removing inactive accounts (lastlog shows last login). Monitor suspicious activity with log analysis (failed login attempts, sudo usage, file access). Set up proper file ownership on shared directories with setgid and appropriate umask. Monitoring and auditing: enable audit logging with auditd, monitor logs for suspicious patterns (excessive failed logins, privilege escalation attempts, unusual file access), set up alerts for critical events, track sudo usage, and regularly review user list in /etc/passwd. Use centralized logging for multi-system environments. Implement file integrity monitoring (AIDE, Tripwire) to detect unauthorized changes to system files.

16. Explain password management in Linux including /etc/shadow, password policies, and the chage command. How do you enforce password complexity and expiration?

Difficulty: HardType: SubjectiveTopic: Password Management

The /etc/shadow file stores encrypted passwords and password aging information, readable only by root. Format: username:encrypted_password:last_change:min:max:warn:inactive:expire:reserved. Last_change is days since epoch of last password change, min is minimum days between changes, max is maximum days before required change, warn is warning days before expiration, inactive is days after expiration before account locks, expire is absolute expiration date. Manage password aging with chage: chage -l username displays aging information, chage -M 90 username sets maximum 90 days between password changes, chage -m 7 username sets minimum 7 days between changes (prevents immediate password change back), chage -W 14 username warns 14 days before expiration, chage -E 2024-12-31 username sets account expiration date, chage -I 30 username locks account 30 days after password expires. Enforce password complexity with PAM (Pluggable Authentication Modules) configuration in /etc/pam.d/common-password (Debian/Ubuntu) or /etc/pam.d/system-auth (RHEL/CentOS). Install libpam-pwquality package. Configure with pam_pwquality.so: minlen=12 (minimum length), dcredit=-1 (require digit), ucredit=-1 (require uppercase), ocredit=-1 (require special char), lcredit=-1 (require lowercase), difok=3 (minimum character changes from old password), maxrepeat=2 (max repeated characters). Password history prevents reusing recent passwords: configure pam_unix.so remember=10 to remember last 10 passwords. Failed login attempts: pam_faillock.so locks accounts after N failed attempts within time window, mitigating brute force. Example: deny=5 unlock_time=900 locks after 5 failures for 15 minutes. Best practices: enforce minimum complexity (12+ characters, mixed case, numbers, symbols), regular password changes (60-90 days max age), prevent password reuse (remember last 10+), account lockout after failed attempts, user education on password security, consider key-based authentication over passwords for SSH, use password managers for complex passwords, and regular password audits with tools like John the Ripper (authorized testing only).

Master Interviews
Anywhere, Anytime

User & Permission Management – Linux & Shell Scripting interview questions

Set overview

Linux & Shell Scripting – User & Permission Management questions (16)

1. Explain the complete process of creating, modifying, and deleting user accounts. Include commands, files involved, and best practices.

Continue your preparation

2. Which command is used to add a new user in Linux?

3. What information is stored in /etc/passwd file?

4. What permissions does chmod 644 set?

5. What does the sticky bit do on a directory?

6. Explain umask in Linux. How does it work and how do you calculate default permissions for new files and directories?

7. What is the purpose of the sudo command?

8. What is the difference between su and su - commands?

9. What are Access Control Lists (ACLs) in Linux?

10. How do you troubleshoot permission denied errors? Describe the systematic approach to identifying and fixing permission issues.

11. Explain the /etc/sudoers file structure and how to configure granular sudo access. Include examples of different sudo configurations.

12. What are service accounts and how should they be managed? Explain best practices for creating and securing service accounts.

13. Explain setuid and setgid special permissions. Provide examples of when they're necessary and security implications.

14. What are best practices for managing a multi-user Linux system? Discuss user isolation, resource limits, and security hardening.

15. Which file contains group information in Linux?

16. Explain password management in Linux including /etc/shadow, password policies, and the chage command. How do you enforce password complexity and expiration?

More sets in Linux & Shell Scripting

Explore related subjects

Master Interviews Anywhere, Anytime

User & Permission Management – Linux & Shell Scripting interview questions

Set overview

1. Explain the complete process of creating, modifying, and deleting user accounts. Include commands, files involved, and best practices.

Continue your preparation

2. Which command is used to add a new user in Linux?

3. What information is stored in /etc/passwd file?

4. What permissions does chmod 644 set?

5. What does the sticky bit do on a directory?

6. Explain umask in Linux. How does it work and how do you calculate default permissions for new files and directories?

7. What is the purpose of the sudo command?

8. What is the difference between su and su - commands?

9. What are Access Control Lists (ACLs) in Linux?

10. How do you troubleshoot permission denied errors? Describe the systematic approach to identifying and fixing permission issues.

11. Explain the /etc/sudoers file structure and how to configure granular sudo access. Include examples of different sudo configurations.

12. What are service accounts and how should they be managed? Explain best practices for creating and securing service accounts.

13. Explain setuid and setgid special permissions. Provide examples of when they're necessary and security implications.

14. What are best practices for managing a multi-user Linux system? Discuss user isolation, resource limits, and security hardening.

15. Which file contains group information in Linux?

16. Explain password management in Linux including /etc/shadow, password policies, and the chage command. How do you enforce password complexity and expiration?

More sets in Linux & Shell Scripting

Explore related subjects

Master Interviews
Anywhere, Anytime