Bug 41908 - Add user filter
Summary: Add user filter
Status: RESOLVED DUPLICATE of bug 56729
Alias: None
Product: accountsservice
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Matthias Clasen
QA Contact:
Depends on:
Reported: 2011-10-17 19:54 UTC by Robert Ancell
Modified: 2012-12-06 19:33 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Robert Ancell 2011-10-17 19:54:38 UTC
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?
Comment 1 Robert Ancell 2011-11-14 23:09:45 UTC
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.
Comment 2 Oliver Henshaw 2011-11-15 02:55:19 UTC
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?
Comment 3 Oliver Henshaw 2011-11-15 04:41:44 UTC
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.
Comment 4 Joseph Daniel Zukiger 2012-01-02 22:23:41 UTC
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.
Comment 5 Matthew Monaco 2012-05-14 18:30:47 UTC
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):

min_uid   = 1000
max_uid   = 10000
exclude   = space separated list of users
include   = space separated list of users
cache_max = 5

user      = someuser
Comment 6 Ray Strode [halfline] 2012-05-14 19:31:03 UTC
See bug 40020 for other discussion about potentially creating a separate config file.
Comment 7 Matthias Clasen 2012-05-15 06:31:26 UTC
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.
Comment 8 Ray Strode [halfline] 2012-12-06 19:33:39 UTC
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.