Why doesn't "su bind" work?

Question

When you do apt-get install bind9, there gets a user bind created.

I'm having some trouble with my bind installation.

See

• How can I add file create read write and delete for a specific user?

• How to allow bind in app armor?

for more information on that.

I tried to debug by suing from root to user bind (from root because I don't know the password).

Usually this works for any user.

But when I type

su bind

I get no error message, but the user on bash is still shown as root and whoami also tells me that I am still root.

If I do the same for any other user, bash changes to that user and whoami also tells me that I am this user.

So... Why can't I su to user bind?

This is what an excerpt from /etc/passwd:

root@zotac:/etc# cat passwd | grep "bind"
bind:x:107:119::/var/cache/bind:/bin/false

I tried replacing /bin/false with /bin/bash, but that does not make a difference. So what is the problem?

Answer 1

A properly configured system, like yours, does not allow successful logins (even with su or sudo -u) as bind. But you can run commands as bind--even a shell, if you need to.

Why This Is (And Should Be) Happening

The user bind is not a user who should be able to log in. This is by design.

bind:x:107:119::/var/cache/bind:/bin/false

/bin/false is bind's login shell. false is not a real shell like sh or bash. Instead, it performs no action, and signals to the calling process that it failed. Configuring a user with /bin/false as its shell is one of the standard ways to make it (potentially) possible to authenticate as the user to run commands, but not possible to effectively log in as the user. When a user has /bin/false as its shell, this is what happens when the user logs on:

1. Authentication occurs. Assuming it succeeds...
2. The shell, /bin/false, is invoked.
3. The shell immediately exits.
4. Since the login shell has exited, the login session is terminated.
5. Now you're back to being root, so commands like whoami show you as root.

If you change your configuration to make it possible for bind to log in, then depending on how you do it and other details of your configuration, you may render your system insecure. You almost certainly should not do this.

Why This Happens Even With /bin/bash Replacing /bin/false

If you modified /etc/passwd directly, I believe it is possible that cached data has not been updated. If you reboot, the problem will likely be solved. But as explained above, this is not really a good idea. If you haven't done so already, I recommend (carefully) editing that line back to the original version (with /bin/false).

Running Commands As bind

Instead, if you really need to run a command as the user bind, use sudo to run the specific command:

sudo -u bind command

And if you really need to run a login shell as the user bind, use sudo to run a shell as bind, and tell the shell to act like an initial login shell:

sudo -u bind bash -l

Replace bash with the name of the shell you want to use, if different.

The -l flag makes bash act like a login shell (see man bash). This corresponds functionally to su - bind (see man su) or sudo -i bind (see man sudo). Except, the shell you specify (in this example, bash) runs, instead of /bin/false.

If you want something that corresponds to su bind or sudo -s bind (a shell that is not a login shell and that mostly keeps the caller's environment variables, including HOME), but runs /bin/bash instead of /bin/false, use this command:

sudo -u bind bash

If for some reason you wanted to use su (running it as root) to run a command as bind, you can accomplish that with the -c flag:

su bind -c command

Things Not To Do

• It's possible to use usermod to change bind's shell from /bin/false to something else. This would make it possible for administrators to use sudo -u -i bind or sudo -u -s bind, and root to use su bind, at least if done properly. But you should almost certainly not do this--it violates the design assumption that no one can log in as bind.
• You can even run sudo passwd bind set a password for bind, so that anyone (except guest) can log in as bind with su, if they know the password. This would also make it possible to log in as bind on a virtual console, via SSH, and possibly even with the graphical login screen. Setting a password for bind is even worse than changing its login shell, and you should not do this.

As detailed above, you don't need to do either of these things.