(In reply to Miloslav Trmač from comment #0)
> For example, allowing any process running as a service user to use chsh to
> change their own shell from /sbin/nologin to something else would be rather
> undesirable.

Oops, this is obviously impossible because chsh asks for the user’s password and service users have password authentication disabled.

Rising needinfo for Ondrej :)

Well, nologin is also used for _normal_ users, if you want to disallow their access.

This is usually done via chsh, which would complain if you specified a path not in /etc/shells, or as the manpage itself says:

"chsh  will  accept  the full pathname of any executable file on the system.  However, it will issue a warning if the shell is not listed in the /etc/shells file. On the other hand, it can also be configured such that it will only accept shells listed in this file, unless you are root."

Also, what's the "cross-package bug" you've mentioned?

And why do you think the warning should be gone? Looking at the code, the manpages and playing with chsh, it seems like you can safely not have anything listed in /etc/shells, not even bash, and be able to login locally (with warnings). However, the warning says that you then might not be able to connect with the user remotely via FTP(as an example), as the daemon wouldn't find your login shell in /etc/shells and might deny your access based on that.

As you pointed out, it was intentional, however it was disputed several times if /sbin/nologin should be there or not ( e.g. https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00887.html ). https://bugzilla.redhat.com/show_bug.cgi?id=53963#c6 raised the security aspect of /sbin/nologin in /etc/shells , however it is there for 13 years without any known flaw related to it.
Yenya suggested similar change as mitr in https://bugzilla.redhat.com/show_bug.cgi?id=70414#c3 , I agree we should patch our shells(5) man page to reflect this Fedora behaviour. If /sbin/nologin is already part of the ubuntu/debian /etc/shells, it might be even possible to convince man-pages upstream to change the wording there.

(In reply to Ondrej Oprala from comment #3)
> Well, nologin is also used for _normal_ users, if you want to disallow their
> access.

I’m not sure an account which cannot get a shell can be called normal… though clarifying that might also be in scope.

> "chsh  will  accept  the full pathname of any executable file on the system.
> However, it will issue a warning if the shell is not listed in the
> /etc/shells file. On the other hand, it can also be configured such that it
> will only accept shells listed in this file, unless you are root."
(Read “can be” as “actually is on Fedora”.)

> Also, what's the "cross-package bug" you've mentioned?
This one.  It’s not _entirely_ clear that this should be just a man-page change and we should not be changing the policy, though just adjusting the man page is my best guess at the right thing to do.

> And why do you think the warning should be gone?
If we are routinely using /sbin/nologin for non-“normal” users and /sbin/nologin is in /etc/shells, consulting /etc/shells to see which users are “normal" won’t work, so we should not have documentation that suggests this is a reasonable thing to do.  (shells(5) is AFAIK the most authoritative, if not the only, documentation of /etc/shells we have.)

> However, the warning says that you then might not be able
> to connect with the user remotely via FTP(as an example), as the daemon
> wouldn't find your login shell in /etc/shells and might deny your access
> based on that.

AFAICS we ship vsftpd using pam_shells by default, i.e. it _does_ check /etc/shells but that check is rather useless.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Same in

> setup-2.9.6-1.fc22.noarch
> man-pages-3.81-2.fc22.noarch

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

I believe this can be closed NOTABUG, as it has been decided to remove nologin from /etc/shells in https://bugzilla.redhat.com/show_bug.cgi?id=1378893

Closing, feel free to reopen if something changes.