Bug 44408

Summary:	not filtered by default shell /bin/nologin
Product:	accountsservice	Reporter:	Joseph Daniel Zukiger <joudanzuki>
Component:	general	Assignee:	Matthias Clasen <mclasen>
Status:	RESOLVED FIXED	QA Contact:
Severity:	critical
Priority:	medium	CC:	bugzilla, oliver.henshaw, rstrode
Version:	unspecified
Hardware:	x86 (IA32)
OS:	Linux (All)
See Also:	https://bugs.freedesktop.org/show_bug.cgi?id=41908 https://bugzilla.gnome.org/show_bug.cgi?id=643441 https://bugzilla.redhat.com/show_bug.cgi?id=670244 https://bugzilla.redhat.com/show_bug.cgi?id=583080 https://bugzilla.redhat.com/show_bug.cgi?id=604965 https://bugzilla.redhat.com/show_bug.cgi?id=708275
Whiteboard:
i915 platform:		i915 features:
Attachments:	Don't use hard-coded minimal UID to exclude users Filter users on nologin rather than minimal UID

Description Joseph Daniel Zukiger 2012-01-02 21:08:01 UTC

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.

Comment 1 Matthias Clasen 2012-02-13 16:40:12 UTC

Looks like the code to do nologin filtering got lost when moving things from gdm to the accountsservice. We should bring it back.

Comment 2 Bastien Nocera 2012-03-07 03:30:13 UTC

Created attachment 58111 [details] [review]
Don't use hard-coded minimal UID to exclude users

We should instead filter on the login shell used.

Comment 3 Bastien Nocera 2012-03-07 03:37:23 UTC

Created attachment 58113 [details] [review]
Filter users on nologin rather than minimal UID

Comment 4 Bastien Nocera 2012-03-07 03:38:53 UTC

Requires the patch from:
https://bugs.freedesktop.org/show_bug.cgi?id=47045
but you might be able to merge it in if you're not interested in the transient correctness ;)

Comment 5 Matthias Clasen 2012-03-07 05:46:05 UTC

Comment on attachment 58111 [details] [review]
Don't use hard-coded minimal UID to exclude users

Review of attachment 58111 [details] [review]:
-----------------------------------------------------------------

Not sure I agree with this one.
Yes, we should filter on the login shell. But that doesn't mean that we should ignore the minimal uid

Comment 6 Matthias Clasen 2012-03-07 05:47:34 UTC

Comment on attachment 58111 [details] [review]
Don't use hard-coded minimal UID to exclude users

Review of attachment 58111 [details] [review]:
-----------------------------------------------------------------

Just looking at my /etc/passwd, there's odd things like sync and halt, which are not /sbin/nologin

Comment 7 Bastien Nocera 2012-03-12 11:36:42 UTC

(In reply to comment #5)
<snip>
> Not sure I agree with this one.
> Yes, we should filter on the login shell. But that doesn't mean that we should
> ignore the minimal uid

The minimal UID is only useful to create new users, nothing else. In fact it creates problems with perfectly normal administration policies (like adding new users should start from UID 5000, but users local to the machine get 500 and above, for example).

(In reply to comment #6)
> Just looking at my /etc/passwd, there's odd things like sync and halt, which
> are not /sbin/nologin

They're already ignored, see the daemon->priv->exclusions hash_table that has every item in default_excludes[] added.

The same scheme work for GDM in the past.

Comment 8 Bastien Nocera 2012-03-12 11:37:05 UTC

(In reply to comment #5)
<snip>
> Not sure I agree with this one.
> Yes, we should filter on the login shell. But that doesn't mean that we should
> ignore the minimal uid

The minimal UID is only useful to create new users, nothing else. In fact it creates problems with perfectly normal administration policies (like adding new users should start from UID 5000, but users local to the machine get 500 and above, for example).

(In reply to comment #6)
> Just looking at my /etc/passwd, there's odd things like sync and halt, which
> are not /sbin/nologin

They're already ignored, see the daemon->priv->exclusions hash_table that has every item in default_excludes[] added.

The same scheme work for GDM in the past.

Comment 9 Matthias Clasen 2012-03-24 08:07:59 UTC

Comment on attachment 58111 [details] [review]
Don't use hard-coded minimal UID to exclude users

Review of attachment 58111 [details] [review]:
-----------------------------------------------------------------

Ok, after rereading the docs for UID_MIN, I agree now.

Comment 10 Ray Strode [halfline] 2012-03-26 12:41:04 UTC

I've pushed this in now with a few changes to also catch /bin/false and /usr/sbin/nologin.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.