220-1102 Question 269
Single answer/etc/passwdA Linux workstation user reports that they can no longer log in at the console after an account change. You boot into a recovery shell and inspect the following line in /etc/passwd for the user jsmith:
jsmith:x:1050:1050:John Smith:/home/jsmith:/bin/false
The account should be able to log in interactively and use a normal shell. Which action should the technician take FIRST to resolve the issue?
- A
Change jsmith's login shell to /bin/bash or another valid interactive shell
- B
Edit /etc/shadow and replace the password hash with the letter x
- C
Delete the user's home directory entry from /etc/passwd so Linux recreates it automatically
- D
Change the UID and GID to 0 so the user can access the system again
Show answer and explanation
Correct answer: A
Explanation
The /etc/passwd file stores account information in colon-separated fields, including username, password placeholder, UID, GID, comment, home directory, and login shell. In this case, the entry ends with /bin/false, which is designed to deny interactive shell access. For a standard user who needs to log in normally, the shell should be a valid interactive shell such as /bin/bash or /bin/sh, depending on system policy. Modern Linux systems typically store password hashes in /etc/shadow, which is why /etc/passwd often shows x in the password field. This follows standard Linux account-management practices documented in the passwd(5), shadow(5), and usermod(8) manual pages. In a real environment, a best practice would be to use a supported command such as usermod -s /bin/bash jsmith rather than manually editing account files when possible.
- A. Correct.
Correct. In /etc/passwd, the final field defines the user's login shell. /bin/false is a non-interactive shell commonly used to prevent logins for service or restricted accounts. If jsmith needs normal interactive access, changing this field to a valid shell such as /bin/bash is the appropriate first step. This directly addresses the symptom shown in the scenario.
- B. Incorrect.
Incorrect. The x in /etc/passwd indicates that the encrypted password is stored in /etc/shadow, not in /etc/passwd. Replacing the password hash in /etc/shadow with x would be invalid and would not correct the login shell problem. This option reflects confusion between the password field in /etc/passwd and the actual password storage in /etc/shadow.
- C. Incorrect.
Incorrect. The home directory field in /etc/passwd specifies the path to the user's home directory; removing it does not cause Linux to recreate the directory automatically. Even if the home directory were missing, that would not be the first issue to address here because the account is explicitly configured with /bin/false, which blocks interactive login.
- D. Incorrect.
Incorrect. Setting UID and GID to 0 would make the account effectively root-level, which is a serious security risk and not an appropriate troubleshooting step. The inability to log in in this scenario is caused by the login shell field, not by insufficient privileges.