Ubuntu

Unable to hide users from login screen / user switcher

Reported by Andrew on 2011-09-23
714
This bug affects 151 people
Affects Status Importance Assigned to Milestone
accountsservice
Confirmed
Medium
accountsservice (Ubuntu)
High
Unassigned
lightdm (Ubuntu)
Low
Unassigned

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

Andrew (andrewkk) wrote :
Stephen Gava (elguavas.) wrote :

same happens here.

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

Launchpad Janitor (janitor) wrote :

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

Changed in lightdm (Ubuntu):
status: New → Confirmed
Changed in lightdm (Ubuntu):
assignee: nobody → Robert Ancell (robert-ancell)
importance: Undecided → Low
Robert Ancell (robert-ancell) wrote :

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.

Changed in lightdm (Ubuntu):
assignee: Robert Ancell (robert-ancell) → nobody
Michael D. (dobmeier-michael) wrote :

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) wrote :

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

Changed in lightdm (Ubuntu):
status: Confirmed → Triaged
Changed in accountsservice (Ubuntu):
status: New → Triaged
importance: Undecided → High
summary: - hidden-users in /etc/lightdm/users.conf are not hidden
+ Unable to hide users from login screen / user switcher
ijk (ijk) wrote :

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

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) wrote :

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) wrote :

@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) wrote :

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

[SeatDefaults]
greeter-hide-users=true

Sebastien Bacher (seb128) wrote :

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) wrote :

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

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.

Changed in accountsservice:
importance: Unknown → Medium
status: Unknown → Confirmed

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.

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?

> 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

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.

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) wrote :

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) wrote :

still active bug then with no work around!!

Migas (migaxmoitax) wrote :

same here with ubuntu 12.04 and unity-2D.

Sebastien Bacher (seb128) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Heathpetersen (heathpetersen) wrote :

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) wrote :

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

e80f00 (e80f00) wrote :

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

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

tags: added: patch

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.

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

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

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

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

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.

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.

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/

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

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.

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.

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

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.

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

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?

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

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

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

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

Changed in accountsservice:
status: Confirmed → Invalid
toobuntu (toobuntu) wrote :

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

toobuntu (toobuntu) wrote :

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

Changed in accountsservice:
importance: Medium → Unknown
status: Invalid → Unknown
Changed in accountsservice:
importance: Unknown → Medium
status: Unknown → Confirmed

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

or individual patches, for that matter

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.

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) wrote :

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) wrote :

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

no longer affects: unity-greeter (Ubuntu)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.