/etc/shells should not contain /bin/false

Bug #295960 reported by drink on 2008-11-09
Affects Status Importance Assigned to Milestone
base-files (Ubuntu)

Bug Description

Putting /bin/false into /etc/shells demonstrates a deep ignorance of Unix and the purpose of the /etc/shells file. That file is meant to contain ONLY VALID LOGIN SHELLS. In the past it was SOP to place /bin/true into /etc/shells; this would allow remote logins (e.g. X11 and ftp) while denying local logins, since by default non-'login' remote logins which did not run the users' shell would and still do permit login only when the user has a valid login shell.

Putting /bin/false into the file is the OPPOSITE of tradition. I understand that Ubuntu may choose to break with tradition occasionally when there is a good reason, but there is no good reason to put /bin/false into /etc/shells, and numerous excellent reasons NOT to - chief among them being that longtime Unix admins and various developers expect to be able to use /bin/false as a NON-VALID login shell. Today we have 'nologin' programs/scripts which are used in place of /bin/false, so arguably it is not necessary for /bin/true to be in the file either; but that is a personal decision left to the systems administrator.

I understand that there is a certain motivation to make things 'just work', but the purpose of the file is to list valid login shells, and even /bin/true has NEVER come in the /etc/shells file by default. This is a POTENTIAL SECURITY RISK because an old software package or a legacy install script may depend on using /bin/false as the user's shell to prevent logins (a star in the password GECOS field might cause strange behavior on some Unixlike operating systems, so this is arguably the more compatible means.)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers