Linux Commands and File Permissions practice questions

chmod 600 /etc/passwd

Why wrong: This would make the file only readable by root, which would break system tools that need to read the file.

chmod 755 /etc/passwd

Why wrong: This adds execute permission, which is unnecessary and a security risk for a text file.

chmod 444 /etc/passwd

Why wrong: This makes the file read-only for everyone, preventing root from writing to it, which is not the default.

find /var/log -atime -1

Why wrong: This finds files accessed, not modified, in the last 24 hours, which is not the requirement.

find /var/log -ctime -1

Why wrong: This finds files with changed status (metadata) in the last 24 hours, not content modification.

find /var/log -mmin -1440

Why wrong: This would work but uses minutes; -mtime -1 is more standard for daily checks, and -mmin -1440 is equivalent but less common.

locate notes.txt

Why wrong: This command relies on a database that may not be up-to-date, so it might not find a recently saved file.

grep notes.txt /

Why wrong: grep is used to search within file contents, not to find filenames; this would not work as intended.

find ~ -name notes.txt

Why wrong: This searches only the user's home directory, not the entire filesystem as required.

chmod 777 /opt/app

Why wrong: This grants full read, write, and execute to everyone, which is excessive and a security risk.

chown user:user /opt/app

Why wrong: This changes ownership to the user, which may break other processes expecting root ownership; it is not minimal.

chmod g+w /opt/app

Why wrong: This adds write for the group, but the script runs as a non-group user, so it would not help unless the user is in the group.

chmod 777 /etc/app/config.cfg

Why wrong: This makes the file readable, writable, and executable by everyone, which is the opposite of the security requirement.

chmod 644 /etc/app/config.cfg

Why wrong: This gives owner read/write but group and others read-only, which still allows non-root users to read the file.

chmod 400 /etc/app/config.cfg

Why wrong: This gives owner read-only, which would prevent root from writing to the file, violating the requirement.

chmod 755 file

Why wrong: This changes permissions to rwxr-xr-x, giving read and execute to everyone, but does not address the group ownership issue.

chmod g+r file

Why wrong: This adds read for the group, but the group is 'admin', not 'staff', so the user's team still cannot access the file.

chown user:staff file

Why wrong: This changes both owner and group; changing the owner may be unnecessary and could cause permission issues if the user is not the intended owner.

chmod g+rx /var/www/html

Why wrong: This adds group read/execute, but the group already has r-x, so this does not change anything if the user is not in the group.

chmod o+rx /var/www/html

Why wrong: This adds read/execute for others, which would work but is less secure than adding the user to the group.

chown www-data:www-data /var/www/html

Why wrong: This changes ownership to www-data, which may work but is not the standard practice; the web server user should be in the group.

find / -type f -perm 0777

Why wrong: This finds world-writable files, not files with SUID set.

find / -type f -perm 4000

Why wrong: This would only find files with exactly the permission 4000 (---S------), which is rare; most SUID files have other bits set.

find / -type f -perm /4000

Why wrong: The / syntax is used for some find versions, but -perm -4000 is the standard POSIX way to match any file with the SUID bit.

chmod 755 script.sh

Why wrong: This sets permissions to rwxr-xr-x, which does allow execution but is not the minimal change; it also adds group and others execute, which may be unnecessary.

chmod 644 script.sh

Why wrong: This is the current permission set and does not include execute, so it would not fix the issue.

chown user:user script.sh

Why wrong: This changes ownership but does not alter permissions; the script still lacks execute permission.

find /usr/bin -user root -perm -6000

Why wrong: This matches files with both SUID and SGID bits set (6000), not either one, so it would miss files with only SUID or only SGID.

find /usr/bin -user root -perm 4000 -o -perm 2000

Why wrong: This is syntactically incorrect; the -o operator needs to be properly grouped with parentheses, and it does not combine the conditions correctly.

ls -la /usr/bin | grep '^...s'

Why wrong: This uses grep to find SUID files but does not filter by owner root, and it does not capture SGID files correctly.

chmod 666 config.cfg

Why wrong: 666 gives write to everyone, which is insecure and not the best practice for a configuration file.

chown appuser config.cfg

Why wrong: Changing ownership to appuser would work but violates the constraint of not changing ownership.

setfacl -m u:appuser:rw config.cfg

Why wrong: While ACLs could work, the scenario does not mention ACL support and the command syntax is correct but not the most standard approach without context.

ls -la /var/log | grep '24 hours'

Why wrong: ls does not have a filter for modification time; grep would not find a '24 hours' string.

find /var/log -atime 0

Why wrong: atime filters by access time, not modification time; the scenario specifies modified.

locate /var/log | sort -m

Why wrong: locate searches a database, not real-time; sort -m merges files, not a time filter.

stat /opt/custom/bin/command

Why wrong: stat shows detailed metadata but is less commonly used for quick permission checks; it is correct but not the standard tool.

file /opt/custom/bin/command

Why wrong: file shows the file type, not permissions or ownership.

chmod /opt/custom/bin/command

Why wrong: chmod changes permissions, it does not display them.

chmod o+r /opt/app/data

Why wrong: This adds read for others, not the group; the group still cannot read.

chmod 644 /opt/app/data

Why wrong: 644 sets rw-r--r--, which gives read to group and others; that works but also grants read to everyone, which may be too permissive.

chown :developers /opt/app/data

Why wrong: This changes the group ownership but does not change permissions; the group still cannot read if permissions remain 600.

grep -r 'Password' /etc

Why wrong: This is case-sensitive and would miss 'password' or 'PASSWORD'.

find /etc -name '*Password*'

Why wrong: This searches for filenames containing 'Password', not file contents.

locate Password | grep /etc

Why wrong: locate searches a database of filenames, not file contents; it also does not support case-insensitive content search.

chown datagroup: /srv/data

Why wrong: This changes the group of only the top-level directory, not its contents.

chmod -R g+rw /srv/data

Why wrong: This changes permissions, not group ownership.

groupmod -R datagroup /srv/data

Why wrong: groupmod modifies group properties, not file ownership.

mv /backup/script.sh /usr/local/bin/

Why wrong: mv moves the file but does not preserve permissions by default; the backup may have different permissions.

cp /backup/script.sh /usr/local/bin/

Why wrong: This copies the file but does not preserve the original permissions; it will use the backup's permissions.

rsync -a /backup/script.sh /usr/local/bin/

Why wrong: rsync -a preserves attributes but is overkill for a single file; it would work but is not the simplest command.

chmod 755 script.sh

Why wrong: 755 sets rwxr-xr-x, which gives execute to owner, group, and others; while it works, it grants more permissions than needed.

chmod +r script.sh

Why wrong: This adds read permission, not execute; the script already has read permission.

chmod 644 script.sh

Why wrong: 644 sets rw-r--r--, which does not include execute permission for anyone.

adduser jdoe

Why wrong: adduser is a friendly frontend that may create home directory and prompt for password, but it is not a single command in the traditional sense; it is interactive.

useradd jdoe && passwd jdoe

Why wrong: useradd without -m does not create a home directory, which is required.

usermod -m jdoe

Why wrong: usermod modifies an existing user, it does not create a new user.

fuser /path/to/script

Why wrong: fuser also shows processes using a file, but it is less commonly used than lsof; it is correct but not the most standard.

ps aux | grep script

Why wrong: This shows running processes with 'script' in the name, but does not specifically show if the file is open.

strace -p $(pgrep script)

Why wrong: strace traces system calls, not a quick check for open files.