setup in Fedora and Red Hat Enterprise Linux added /sbin/nologin and /usr/sbin/nologin to /etc/shells. This violates security assumptions made by pam_shells and some daemons which allow access based on a user's shell being listed in /etc/shells. Under some circumstances, users which had their shell changed to /sbin/nologin could still access the system. Note that SELinux and gdm (and probably others) have special-case workarounds for this issue. Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1378893 Prior discussions: - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UCUWTT63JS72R7ROFE46ZVUZLFN3K2MZ/#UCUWTT63JS72R7ROFE46ZVUZLFN3K2MZ - https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00887.html
Created setup tracking bugs for this issue: Affects: fedora-all [bug 1571103]
Statement: Preventing a user from accessing the system without deleting their account is not a simple matter. For utmost security, the account should be deleted. Short of this, we recommend a three-pronged approach: * change the user's login shell to a harmless command that is not in "/etc/shells" (for example "/bin/false") to prevent commands being run on their behalf * lock the user's password with "usermod -L" to prevent authentication with pam services * prevent access to the user's home directory with "chmod 0" or "chown root" and "chmod 700" to prevent authentication with ssh keys etc
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2018:3249 https://access.redhat.com/errata/RHSA-2018:3249
The proposed change, as pushed through in setup-2.8.71-10.el7.noarch, breaks large numbers of no-shell ftp only accounts (users that can ftp but not login or ssh in). Besides, the diagnostic given after the change is the incorrect "Wrong password" (rather than, say "login prohibited" or "account disabled"). This is going to give countless sysadmins an hour or so of fun, as complaints about tens of now broken accounts call for a fix. While I feel that - seeing as /etc/shells has existed in its current form for 14 year - the change should happen in /etc/shells.rpmnew, I also think that the very least, enhanced prominence should be given to the "fix". Also the error message should be improved to adhere to the actual reason of access denial. Also note that the current way to achieve the present behavior (user cannot have an interactive shell, but can still use ftp) is sticking nologin (or something even less standard, such as /bin/true) in /etc/shells (as no alternative is provided). This means that whatever security enhancements this change intends to put in effect will quickly be undone in several installations.