1Z0-888 · Question #48
An administrator installs MySQL to run under a mysql OS account. The administrator decides to disable logins to the mysql account by using /nologin or /bin/false as the user's shell setting. Which…
The correct answer is A. The mysql user needs a login and its home directory must be the base directory of the installation. Option A as marked is actually incorrect - D is the technically accurate answer, and this appears to be an error in the question's answer key. Setting /bin/false or /nologin as the shell for the mysql OS account is a standard Linux security hardening practice. It blocks anyone…
Question
Options
- AThe mysql user needs a login and its home directory must be the base directory of the installation.
- BThe OS needs to allow logging in as mysql so that administrative tasks can be performed.
- CThis prevents mysql from starting when standard startup scripts are used.
- DThis prevents creation of a command shell with the mysql account, while allowing mysqld to run.
How the community answered
(19 responses)- A79% (15)
- B5% (1)
- C5% (1)
- D11% (2)
Explanation
Option A as marked is actually incorrect - D is the technically accurate answer, and this appears to be an error in the question's answer key.
Setting /bin/false or /nologin as the shell for the mysql OS account is a standard Linux security hardening practice. It blocks anyone from spawning an interactive shell as that user, but it has no effect on running daemons or services - mysqld runs as a background process launched by init/systemd using the User=mysql directive, which never requires an interactive login shell. This is precisely why administrators do this.
Why the distractors are wrong:
- A is wrong because
mysqlddoes not need an interactive login shell, and the home directory requirement (typically the data directory) is unrelated to the shell setting - B is wrong because MySQL administrative tasks are performed via the MySQL client using MySQL's own privilege system - not by OS-level login as
mysql - C is wrong because standard startup scripts (systemd units, SysV init) are unaffected by a
/bin/falseshell; they invoke the binary directly under that user
Memory tip: Think of the mysql OS account like a jail cell - /bin/false locks the door so humans can't walk in, but the automated machinery (mysqld) that runs inside the cell keeps working fine. You're preventing unauthorized interactive access, not stopping the service itself. This pattern applies broadly: www-data, nobody, postgres - service accounts routinely use /bin/false for security.
Topics
Community Discussion
No community discussion yet for this question.