Some users like to filter out certain users from the login screen / user switcher etc. The accounts can still be logged into but are not shown in the GUI. Suggest adding a filter list to AccountsService that does this, perhaps via a "hidden" property on users that should not be shown in a GUI?
I've been asking around to find out why you'd not want to log into certain accounts. The cases I've head so far are: - System users showing up (e.g. mysql. This seems like an OS bug) - Running a server and having remote logins. There may be accounts that you want to log into to control the server (i.e. over SSH) but not graphically. The last case makes it sound like there potentially should be a per-seat filter.
My use case is a separate account used to develop or to build packages. This provides environmental isolation from the everyday user account and some security - the separate account might have additional system privileges or private keys. For example: Mock - http://fedoraproject.org/wiki/Projects/Mock#Build_User kde development - using (now outdated, i think) advice such as at http://techbase.kde.org/Getting_Started/Build/KDE4_%28bn_IN%29#Create_a_user_account_for_KDE4_development A test account for a very old version of amarok with X forwarding Accounts that can only be accessed by ssh or that don't make sense to log in directly (and are just noise for other users on the machine) but that are otherwise still normal user accounts with home directories and that don't really belong in the system account pid range. Arguably some of this is better handled by virtual machines nowadays; but the separate build user case for mock is, I believe, still strong. And the ssh keys in a separate account case is reasonable, isn't it?
To cut through some of the guff, this use case boils down to - Accounts intended for local ssh logins. They may have privileges or contain secrets not suitable for day-to-day use. and perhaps - Testing accounts that users at the greeter don't need to be bothered with (whether on a single-owner or a shared machine). Not for security, just aesthetics.
Add a case for users defined but not allowed to log in: Certain kinds of sandbox users, for example users which are sudo switched to, to perform actions which one might not like to perform as a regular user with login capability. This is a traditional admin technique, actually.
I find it incredibly annoying that this dbus daemon does not just have a config file. It's even worse that it used the GDM config file to get info about automatic login. What's wrong with a config file with something like the following format (I can work on implementation but I don't want to do the work if it has no chance at being accepted by Mathias): [Cache] min_uid = 1000 max_uid = 10000 exclude = space separated list of users include = space separated list of users cache_max = 5 [AutoLogin] user = someuser
See bug 40020 for other discussion about potentially creating a separate config file.
Excluding accounts from the accountsservice listing is not the right solution. It would also make these accounts disappear from the user panel - and you probably want to be able to edit them there. This can either be a display manager configuration, or it can be a per-user hide-from-userlist flag that display managers can consult, but defining the exact semantics of that flag would need some thought.
There's a patch on a different bug, so duping this one to it. *** This bug has been marked as a duplicate of bug 56729 ***
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.