Unable to hide users from login screen / user switcher

[Andrew]

Users that I have appended to the 'hidden-users' field in /etc/lightdm/users.conf are not actually hidden. They are still listed on the login screen and in Unity's user switching menu.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: lightdm 0.9.7-0ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-11.18-generic 3.0.4
Uname: Linux 3.0.0-11-generic x86_64
ApportVersion: 1.23-0ubuntu1
Architecture: amd64
Date: Fri Sep 23 11:44:29 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Beta amd64 (20110413)
SourcePackage: lightdm
UpgradeStatus: Upgraded to oneiric on 2011-09-23 (0 days ago)
mtime.conffile..etc.lightdm.users.conf: 2011-09-23T08:46:55.039175

[elguavas (elguavas.)]

same happens here.

also changing 'minimum-uid' in /etc/lightdm/users.conf has no effect either.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Robert Ancell (robert-ancell)]

This occurs because lightdm prefers to use AccountsService if it is available (it is on the default Ubuntu install). So this configuration is ignored. I don't think accounts service provides this option.

[Michael D. (dobmeier-michael)]

The last answer of Robert sounds like as if the described behavior is no bug but a feature ;-)
So perhaps my question is, if this could be a point for the wish list, that the configuration of users.conf will be looked up after getting the usernames/user-ids of the accounts service, so there will be a possibility to hide some users in the list.
I don't know the mechanism of getting the user-list in lightdm, so I don't know, if this is possible?

[Robert Ancell (robert-ancell)]

Not a feature, but it can't/shouldn't be solved in LightDM. I've opened a bug against accountsservice so the feature can be implemented in there. (It has to be in the accounts service as other programs contact that for the list of users, i.e. if we blocked certain users in LightDM, then they would still show in the user switcher).

[ijk (ijk)]

Please add a brief comment to
/etc/lightdm/users.conf to explain.

[Robert Ancell (robert-ancell)]

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?

[Rhialto (rhialto-xs4all)]

I would say it is a security problem to have any users show up at all.
There doesn't even seem to be an option to *always* hide *all* users.

[Fabian Köster (maestro-alubia)]

@Rhialto:

I dont see why this is a security risk to show all users. On UNIX-like systems unprivileged users usually can read /etc/passwd and therefore all user-names on this machine (unless they are managed by LDAP or similar).

[Robert Ancell (robert-ancell)]

Rhialto, you can disable all users by settting the following in /etc/lightdm/lightdm.conf:

[SeatDefaults]
greeter-hide-users=true

[Sebastien Bacher (seb128)]

Hey Aurélien, is that something you would be interested to work on? It would need adding support for hiding users to accountsservice and get lightdm to use it

[Sebastien Bacher (seb128)]

Robert says that there is no lightdm change require, the service should just export the right list of users

[Robert Ancell (robert-ancell)]

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.

[Yoho-ahoy (yoho-ahoy)]

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?

[Yoho-ahoy (yoho-ahoy)]

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.

[Joudanzuki (joudanzuki)]

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.

[Neil Broadley (scaine)]

Another use case is corporate. Desktop roaming in an AD environment would result in your PC being populated in the greeter by anyone who happened to use your PC while you were on holiday. Or if support staff login to check a support call, or if we get the user to login at another PC to troubleshoot an issue.
So the use case is still aesthetics, but in my environment at least, you'd have greeters with 10+ entries on each PC and a lot of angry and confused staff wondering why they see all this spurious stuff on their login screen.

Finally, it's obviously detrimental to security that cleaners can glance at login screens to gather a list of valid usernames. There might be other ways to do this as a cleaner, but Ubuntu's greeter makes this stupidly easy.

As a wishlist item, therefore, I'd like the greeter to support the concept of "only ever show this user". Not sure what to log this against though?

[James Gifford (jamesgifford)]

> 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.

I think this was in the original bug report, but I agree. I use this a lot an frequently have to figure out "ok, was I just trying to log into packaging-test, server-test, vm-test or me?".

> This is a traditional admin technique, actually.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/857651
>
> Title:
> Unable to hide users from login screen / user switcher
>
> Status in D-Bus interfaces for querying and manipulating user account information:
> Confirmed
> Status in “accountsservice” package in Ubuntu:
> Triaged
> Status in “lightdm” package in Ubuntu:
> Triaged
>
> Bug description:
> Users that I have appended to the 'hidden-users' field in
> /etc/lightdm/users.conf are not actually hidden. They are still listed
> on the login screen and in Unity's user switching menu.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 11.10
> Package: lightdm 0.9.7-0ubuntu1
> ProcVersionSignature: Ubuntu 3.0.0-11.18-generic 3.0.4
> Uname: Linux 3.0.0-11-generic x86_64
> ApportVersion: 1.23-0ubuntu1
> Architecture: amd64
> Date: Fri Sep 23 11:44:29 2011
> InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Beta amd64 (20110413)
> SourcePackage: lightdm
> UpgradeStatus: Upgraded to oneiric on 2011-09-23 (0 days ago)
> mtime.conffile..etc.lightdm.users.conf: 2011-09-23T08:46:55.039175
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/accountsservice/+bug/857651/+subscriptions

[Matthew Monaco (dgbaley27)]

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

[Rstrode (rstrode)]

See bug 40020 for other discussion about potentially creating a separate config file.

[Matthias Clasen (mclasen)]

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.

[urusha (urusha)]

I think global exclusion option is needed. Imagine a big domain environment where there are about 20 admins. And all these admins are policykit admins. Once you try to use policykit somehow, all these admin accounts will appear in the panel, but I don't really need them there. The same for login screen - if you are admin, then I think you know how to type your account name. The same time a typical user shouldn't see this trash of unknown strange account names.

Or another way is to implement some cache setting (suggested my Matthew Monaco). If cache is set to 1, then only the last logged user is shown.

The best of course is to implement both of these features.
Thanks.

[t0m5k1 (tom-tomsbox)]

so what is the fix for this?
how do i remove usernames from lightdm that have no purpose being there IE:
the username used to run lightdm = lightdm
UID= 999

the above user is listed & if i change the UID to 499 or less lightdm fails to run!!!!!!!!!!!!!!!!!

[t0m5k1 (tom-tomsbox)]

still active bug then with no work around!!

[Migas (migaxmoitax)]

same here with ubuntu 12.04 and unity-2D.

[Sebastien Bacher (seb128)]

thanks for your interest but please use the "Does this bug affect you?" button on top of the bug table rather than comments to confirm you get the issue

[Eoin (eoin-malins)]

10+ months later and this is still an issue. All our users log in via LDAP. I'd really like to have this fixed so we don't have a lab of machines that display what the local admin username is.

[Mattia Rizzolo (mapreri)]

for now, i worked around setting the UID < 1000.

I have 3 user hide from lightdm with UID 955 956 957

[Edmund Laugasson (ed-lau)]

There is also problem with shells.

In the file /etc/passwd I set:
user:x:1001:1001:,,,:/home/user:/bin/false

In file /etc/shells I added
/bin/false

Also checked:
# ls -l /bin/false
-rwxr-xr-x 1 root root 22896 apr 1 06:09 /bin/false

But still can "user" log in as regular user through GUI. I would like to create user for FTP server (vsftpd), that works only with FTP and not as regular user.

I noticed, that at the file /etc/lightdm/users.conf there is written:
hidden-shells=/bin/false /usr/sbin/nologin

What does this mean? If /bin/false is hidden, then it is not active and user can still log in? I even tried to remove that /bin/false but it didn't help - still can user log in even its shell is /bin/false

[funicorn (funicorn)]

one of the most creative thing of linux developers is, they are very good at transforming a bug into a feature.

[Heathpetersen (heathpetersen)]

What about creating a system group like "noguilogin" that accountsservice uses to determine whether a gui login is allowed and passes that as a flag via dbus with other requested user information. Then all other services that use accountsservice can refer to this when validating whether an X session should be allowed. Also, services that don't utilize accountsservice can just look for membership in the group.

Another option may be as simple as changing lightdm so there's a way to disable using accountsservice. Then you could edit users.conf as you normally would. Not pretty, but it gets the job done.

[Sergio Callegari (callegar)]

Any good reason for removing something that used to work perfectly (kdm) and substituting an evidently half backed replacement for it?

[e80f00 (e80f00)]

Created patch against latest ubuntu source package.

It creates the option to write a key-value-pair to a configuration file named /etc/accountsservice.conf,
in which you can specify with the key "hidden-users" a space separated list of the hidden users.

Example content of /etc/accountsservice.conf:

#
# accountsservice config file
#
# [Users]
# hidden-users = space separated list of users to exclude
#
[Users]
hidden-users=not_me imhidden

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "add-config-file.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Matthew Monaco (dgbaley27)]

The hardcoded default_excludes is really annoying. It's about time we had support for a configuration file. The attached patch set includes this support.

It adds support for [UserList]/Excludes which is shipped with the list of users currently hardcoded in default_excludes.

It also adds support for [UserList]/MinUID with -- as far as I can tell -- a common default of 1000. However, this is now easy for distributions to modify.

[Matthew Monaco (dgbaley27)]

Created attachment 69500
0001-util.h-add-missing-headers.patch

[Matthew Monaco (dgbaley27)]

Created attachment 69501
0002-cfg-initial-support-for-a-configuration-file.patch

[Matthew Monaco (dgbaley27)]

Created attachment 69502
0003-cfg-replace-default_excludes-with-configuration-file.patch

[Matthew Monaco (dgbaley27)]

Created attachment 69503
0004-cfg-add-option-for-minimum-uid.patch

[Rstrode (rstrode)]

Hey, I'd prefer if you added metadata to each users config file instead of introduciting a new file.

Also, one thing to think about is accountsservice is used in various places to get a list of users

1) the login screen
2) the control center panel

maybe it would make sense to show the user in the panel even when not in the login screen? So we may want two keys.

[Matthew Monaco (dgbaley27)]

Ray, I agree that more keys can be added, but all this does is pull a really arbitrary hard-coded list out of the binary into a config file. (And re-add Minimum UID because it made sense but no-one could agree on a value).

As for the per-user config file, I gotta disagree with you. Those are in /var/lib/... which doesn't really suggest they are intended to be done by hand. Also, the minimum UID is global behavior. I could see adding an option like Visibility to the per-user config which can be always on, no-cache, or off, .... But why block which IMO is more of a bug-fix because it also makes you want a new feature.

[Rstrode (rstrode)]

I think we also want to keep a separation between admin configuration and distro configuration.

We should probably have two files, one in data dir and one in /etc/accountsservice/

[Rstrode (rstrode)]

(by data dir, i mean $(datadir), i.e. /usr/share/accountsservice)

[Matthew Monaco (dgbaley27)]

I agree, but I didn't want to put too much time into it before I knew it might be accepted.

Do you think that a single file in /usr that's overridable in /etc is enough? I could see a case for a config.d, lexographically sorted set of config files so that a package could drop in an exclude for a specific username that it installs.

[Rstrode (rstrode)]

I think distros should be able to have their list which includes adm, lp, and nobody, and admins should be able to augment the list with their own users that could include tarball installs of 3rd party software and specific real users they want to conceal.

I'd say the distro file would go in /usr and the admin file in /etc. Note, it would be bad if the admin file overrode the list instead of augmenting it.

I don't think config.d makes sense. we have /var/lib/AccountsService/users/foo already that stores metadata about a specific user foo. that metadata could have "exclude from user list" or "exclude from control center panel" in it, I suppose.

[Matthew Monaco (dgbaley27)]

Ok Ray. Hopefully I can finish it off this weekend. (The only thing about /var is, it seems like it's bad form to install files there, but lets not get hung up on that).

[Rstrode (rstrode)]

well, the files are usually written there by accountsservice in response to dbus calls (e.g. from changes to gnome-control-center or whatever).

I guess we could introduce a accountsctl cli utility or so for managing the files, so the admin doesn't have to edit the /var files directly and doesn't have to use dbus-send.

[Matthew Monaco (dgbaley27)]

Ok Ray,

I still need to add the config file under /usr/lib, but check it out so far [1].

This takes "Exclude" from either the config file(s) or the per-user file under /var/lib. I tried to make a distinction between a system account and an excluded account. The check for a system account is similar to what the daemon_local_is_excluded() function did. I don't think the check for HAVE_GETUSERSHELL was working because I have those functions but HAVE_GETUSERSHELL wasn't defined. I just removed the ifdef for now...

I still am including the MinimumUID setting. I think it would be best to default this to SYS_UID_MAX from /etc/login.defs, but I don't know the best way to retreive that value.

[1] https://github.com/mmonaco/accountsservice/tree/exclude-v2

[Matthew Monaco (dgbaley27)]

https://github.com/mmonaco/accountsservice/commits/exclude-v3

Add's a config file to /lib/... and /etc/...
Excluded= and MinimumUID config options.

MinimumUID in /etc overrides /lib. Exclude in /etc is combind with /lib

Add's an excluded property to the User type and the DBus handlers for manipulating this type

Admin users are not cached. Excluded users are still cached, but they are not returned by ListCachedUsers... I think the best thing would be to just add a new method such as ListGreeterUsers() and get the DMs to use this instead. Thoughts?

[Rstrode (rstrode)]

hey, i just got back from a vacation away from computer (since the 16th), i'll look over your stuff soon!

[Rstrode (rstrode)]

*** Bug 50103 has been marked as a duplicate of this bug. ***

[Rstrode (rstrode)]

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 ***

[Rstrode (rstrode)]

*** Bug 41908 has been marked as a duplicate of this bug. ***

[toobuntu (toobuntu)]

Remote Watch should be updated to:
https://bugs.freedesktop.org/show_bug.cgi?id=56729

[toobuntu (toobuntu)]

Upstream 41908 was marked invalid as a duplicate of upstream 56729, for which there is a patch. Updating Remote Watch accordingly.

[Matthias Clasen (mclasen)]

Could you attach a squashed patch here ? I prefer to use splinter to review it

[Matthias Clasen (mclasen)]

or individual patches, for that matter

[Rstrode (rstrode)]

I'm on the same page as Matthias, I think. I started to look into merging this today, but I ran into a few issues that would be better enumerated using bugzilla. If you could attach the individual patches that would be great.

[e80f00 (e80f00)]

Hello,

Its great that you want to review the changes. But why do you require them to be uploaded to bugzilla? Why do you not just retrieve them from github?

git clone https://github.com/mmonaco/accountsservice.git
cd accountsservice
git checkout origin/exclude-v3
git format-patch -8

(You could replace "-8" with "master", but due to bad branching this would prepend some unrelated commits from accountsservice.)

[Gunnar Hjalmarsson (gunnarhj)]

Creating a user with UID < 1000 works for me as a workaround, since I'm using lightdm-gtk-greeter, which has an "Other" option that allows you to type the username of the account you want to log in to. unity-greeter does not have this option, so a modification to unity-greeter seems to be needed to fix this bug.

[Gunnar Hjalmarsson (gunnarhj)]

Please disregard my comment #61. I missed the existence of the "greeter-show-manual-login" lightdm config option.

[Luca Borrione (luca.borrione)]

Still an issue on ubuntu 14.04

[Sebastian Unger (sebunger44)]

Given that there is a patch available for the upstream bug, could Ubuntu pull that into it's version of accountservice?

[Sergio Callegari (callegar)]

Bug is even worse with kde where

greeter-hide-users=true

does not work.

[Ray-Ven (ray-ven)]

could at least "don't show last logged in network users" work somehow?

[Ray-Ven (ray-ven)]

workaround:
delete line 143 (username section, containing text: greeter.lastLoggedInUser)
/usr/share/kde4/apps/lightdm-kde-greeter/themes/classic/main.qml

[Micheal Waltz (ecliptik)]

This bug also causes all users home directories to mount if they're setup in autofs. This is especially detrimental if your autofs maps contain thousands of users. Lightdm and autofs will slowly grind through mounting home directories looking for:

~/.dmrc
~/.face
~/.face.icon

These mounts stay around in /etc/mtab, which causes reboots/shutdowns to take extremely long while the system then umounts all the directories.

This not only affects the local system, but if hundreds of systems in an environment are doing this it causes unnecessary load on backend services.

[Sam Brightman (sambrightman)]

Created attachment 106996
squashed patch from github

I was surprised and disappointed that this bug had stalled due to disagreement over review methodology. I have followed the instructions above (the history is a little messy) and attached this squashed patch. Individual commit patches are also possible of course.

[Kieran Grant (kieran-grant)]

The workaround I am using to this bug is simple:
Copy /var/lib/AccountsService/users/root to /var/lib/AccountsService/users/user
It's is probably a bad thing to do...

What actually happens if one uses SystemAccount=true in that file, as far as I understand (correct me if I am wrong) that won't grant any special powers to that user, still relies on group membership and PolicyKit rules.

Essentially as a temporary workaround the following lines hide the user:
[User]
SystemAccount=true

[Ｖ字龍(Vdragon) (vdragon)]

Hi Matthias (or others), can anyone start reviewing the patch? (puppy-dog eyes)

[Peter Passchier (peter-passchier)]

Set the user to be a SystemUser in /var/lib/AccountsService/users works.
I would be more interested in a whitelist feature, so newly created unworthy users don't have to be blacklisted.

Why is there not a simple requirement like: only members of the lightdm group are allowed to use lightdm??

[Christian Ehrhardt (paelzer)]

I was made aware in bug #1667113 that this seems to be the root bug to dup this onto.
I know this comes down to accountsservice, as others not using it like sddm are just fine.

If we stick to depend on accountsservice, then it comes down to the following
$ dbus-send --print-reply=literal --system --dest=org.freedesktop.Accounts /org/freedesktop/Accounts org.freedesktop.Accounts.ListCachedUsers

Which should get some sort of the old hiddenShells feature back to exclude those users.

Could someone of the desktop Team give this a look from the 18.04/gnome-shell POV - will this go away?

[Rolf Leggewie (r0lf)]

Why am I seeing this in a bionic fresh install when I did not see this in trusty?
How can I workaround this very annoying and very old bug?

[Rolf Leggewie (r0lf)]

bug 1674765 and https://askubuntu.com/questions/92349/how-do-i-hide-a-particular-user-from-the-login-screen have information how to deal with this

[Gitlab-migration (gitlab-migration)]

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/accountsservice/accountsservice/issues/37.

[Christian Ehrhardt (paelzer)]

The Dup 1667113 had tracked some more affected packages - since all are dupped on this bug here let me add those tasks here so that all component owners are aware.

[Christian Ehrhardt (paelzer)]

Piorities are a bit odd, eventually all packages affected (low prio as they can't do much about it) actually depend on lightdm to resolve it (prio medium) which depends on accountsservive to implement some shell-filter feature (prio high).

TL;DR as there was a lot of discussion up to now:
- users need a way to be hidden other than "uid is low"
- [1] outlines the place/feature we'd need to get back what we had in the past
- [2] outlines that this is a regression and should be handled in lightdm/accountsservice and not all indirectly affected packages

Note: the updated upstream bug is [3], but since this is still a semi-static list instead of detecting hidden shells as it did in the past it is not perfect for what would be needed.
Furthermore nothing happened on this bug for quite some time.
And finally due to being a semi-static list it is almost worse than the workaround of
  echo -e "[User]\nSystemAccount=true" > /var/lib/AccountsService/users/libvirt-qemu
Which could at least be a per-package owned drop-in config.

Once more I'd ask the Desktop Team to evaluate how this could be solved.
At least Towards 20.04 we should get rid of this annoyance for users.
Please let me know if:
- there is any chance that we get a hidden-shell filtering into accountsservice that will fix all affected packages at once?
OR
- if this will not happen and affected packages are supposed to each use the drop-in config. Which means a denial of the argument that was made in [2]

While I'd appreciate getting the right solution (accountsservice filters) we were stalled for too long to use the workaround solution by waiting for it to resolve. So I hope kicking this (once more) helps to at least get to some solution for the users.

[1]: https://bugs.launchpad.net/accountsservice/+bug/857651/comments/73
[2]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1667113/comments/23
[3]: https://gitlab.freedesktop.org/accountsservice/accountsservice/issues/37

[Christian Ehrhardt (paelzer)]

Since so many components are involved a fix/change might have been missed.
And since I recently didn't hear anything about this otherwise rather hot bug I was giving focal a try.

It turns out that this was indeed improved. Only the user of pkg:ifmail user fdt name "Fidonet" is still visible. All other formerly affected packages are good in Focal.
I can't (without digging through history a lot) say what fixed that but I'll update the bug tasks accordingly. Setting Focal fixed and marking Bionic/Xenial as still affected releases.
The backport tasks for those packages are incomplete thou as it is unclear which change in which package fixed it for Focal.

Note: This is only speaking for the "default config" of Ubuntu Desktop as in 20.04 we know that certain environments will behave differently (e.g. KDE never was affected).