Comment 9 for bug 908140

Apparently, this (new?) login component has completely changed the (unwritten?) agreements about what users should be filtered out of the user list in the login dialog.

Traditionally, when presenting a list of users to choose from when logging in, a user whose login shell is specified as /bin/nologin will not be included in the list.

Having a filter list as an extra method is okay (see bug 41908), but it's not the traditional method, and silently changing the behavior is a potential security risk.

If, in keeping with the (in my opinion, ill-advised) shift to capabilities, it is deemed desirable to go with a configurable lower limit on numeric user ids and a filter list, there should at least be some serious public discussion (as, on distro user lists) before the change is implemented, and there should be an incubation period during which both the filter list and the nologin shell are recognized.

I personally would prefer the traditional behavior be kept. There is no reason, on desktops or servers, for /bin/nologin users to be offered the opportunity to log in, in most cases. For those that prefer a separate filter list, the configuration file could be allowed to override the traditional behavior on a per-user basis, whether to show or hide. (Reference bug 41908.)

If the change was made to accommodate wireless carriers who might be deluded about the ability to "keep the platform more secure" by preventing all non-graphical logins, it would be better to add a /bin/guiloginonly default shell value.

Filtering on lack of specified password is a good option, but is also contrary to traditional administration techniques. If such behavior is to be included, it should be set or unset in the configuration files, as well.