System users appears in Ligthdm and user switcher (Accountsservice has no filter for shell types)

Bug #1667113 reported by Franck on 2017-02-22
160
This bug affects 31 people
Affects Status Importance Assigned to Milestone
accountsservice (Ubuntu)
High
Unassigned
base-passwd (Ubuntu)
Undecided
Unassigned
ceph (Ubuntu)
Undecided
Unassigned
ifmail (Ubuntu)
Undecided
Unassigned
libvirt (Ubuntu)
Undecided
Unassigned
lightdm (Ubuntu)
Undecided
Unassigned
netqmail (Ubuntu)
Undecided
Unassigned
sddm (Ubuntu)
Fix Released
Unknown

Bug Description

"Technical" user libvirt Qemu appears in the list of user in Ligthdm, among the real regular users. It probably shouldn't

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: libvirt-bin 2.5.0-3ubuntu2
ProcVersionSignature: Ubuntu 4.9.0-15.16-generic 4.9.5
Uname: Linux 4.9.0-15-generic x86_64
NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
ApportVersion: 2.20.4-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity:Unity7
Date: Wed Feb 22 22:09:24 2017
InstallationDate: Installed on 2017-02-01 (21 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Alpha amd64 (20170201)
KernLog:

SourcePackage: libvirt
UpgradeStatus: No upgrade log present (probably fresh install)

Franck (alci) wrote :

Hi,
thank you for the report - I can confirm the issue.
This was caused by fixing bug 1637601.
This was brought up on IRC two days ago and I was already polling for opinions on the original but.

There are way more such high-id users in there and I wonder why they would not show up.
Maybe there is some filtering mechanism that I didn't know about yet.

Adding a base-passwd task as they should be the best experts knowing how to deal with that (Authority for allocating such IDs).
Also I'm gonna subscribe all participants of the old bug here.

Changed in libvirt (Ubuntu):
status: New → Confirmed

There are also allocations for mysql, ceph and others.
Is libvirt just the one installed on a system with a gui more commonly?
At least mysql should have some footprint ...

Hmm I just checked mysql despite being allocated at 64001 becomes a <1000 number on install.
So that is no good example.

But I found that ceph is using its:
$ id ceph
uid=64045(ceph) gid=64045(ceph) groups=64045(ceph)

Probably for a similar reason as libvirt - to stay consistent across nodes.
I'll check if they show up as well ...

I currently only have a KDE/sddm system and there ceph does not show up there.
I'll get access to another system later today and check there for ceph - maybe we can learn the trick from it how to hide.

Maybe I can spawn a new 16.04.2 default ISO to test locally sooner.

Note: this is only affecting new installs, as he update keeps the old UID. So if there was a libvirt user it stays as-is.

Ok,
new guest, after installing the software I have several high User IDs:
libvirt-qemu @ 64055
ceph @ 64045

I see, it is "just the same" for ceph.
So it might be a more widespread generic issue that has no solution yet, but libvirt just has more exposure on UI based systems to be noticed faster?

The user Objects have an attribute for system accounts:
property Boolean SystemAccount
Whether or not the account is a system account, such as adm. System accounts aren't returned by ListCachedUsers and should generally be ignored.

It also has a shell property, but that (by default) seems to have no impact on listCachedUsers
property String Shell, method SetShell(String path)
The user's login shell.

ListCachedUsers then is what is used by lightdm to fetch the list:
method ListCachedUsers()
returns: users: an array of paths for the user objects
Returns a subset of the users who exist, typically those who have logged in recently, for populating chooser lists such as those used by GDM's greeter.
Currently the accountsservice process scans /etc/passwd for users, filters out those with UID values which are below a threshold point to screen out system users, and sorts the rest by the number of times the users in question appear in /var/log/wtmp. Above a certain length, it's expected that the caller will disregard the list and present only an entry field. The entry field always needs to be available because we know that some results may be missing from this list.

Best API def I found so far is from sssd:
https://fedorahosted.org/sssd/wiki/DesignDocs/AccountsService

Call is from lightdm at load_users in common/user-list.c

This can be reproduced more easily by a direct dbus call:
$ dbus-send --print-reply=literal --system --dest=org.freedesktop.Accounts /org/freedesktop/Accounts org.freedesktop.Accounts.ListCachedUsers

Changed in ceph (Ubuntu):
status: New → Confirmed
Changed in base-passwd (Ubuntu):
status: New → Invalid
summary: - Libvirt Qemu appears in the list of users in Ligthdm and user switecher
+ System users appears in Ligthdm and user switcher (Accountsservice has
+ no filter for shell types)

So while I understand to unify code paths by relying on accoutnsservice lightdm needs to get back the feature of "hidden-shells=" IMHO.

So in some sense this is a regression in lightdm due to the change to use accountsservice.

The solution clearly extceeds my Dbus-foo, but shouldn't lightdm be able to get back "hidden-shells" by implementing a filter on the "Shell" property of each user that accountsservice provides?

Maybe this was discussed in the lightdm/accountsservice communities - I'm not part of them and search engines didn't find it for me - but given how often the question how to hid users came up I'd think some discussion on the shell filtering might already exist.

Waiting for the expertise of the triagers of lightdm/accountsservice on that bug now.

Found more in fidonet and qmail, adding tasks.
But the more that are affected the more I think then general solution in lightdm would be the right thing to do.

no longer affects: fidogate (Ubuntu)
Changed in ifmail (Ubuntu):
status: New → Confirmed
Changed in netqmail (Ubuntu):
status: New → Confirmed

Christian,

Thanks for handling this.

> But the more that are affected the more I think then general solution in lightdm would be the right thing to do.

Yes, that's my interpretation too -- and it was my impression from the beginning, with your report/analysis, as I couldn't find anything we were doing wrong with the useradd of a system account, and specially due to this documentation statement (comment #7):

> [...] filters out those with UID values which are below a threshold point to screen out system users [...]

Which does not cover the possible conditions for a system user (man 8 useradd):

       -r, --system
           Create a system account.

           System users will be created with no aging information in /etc/shadow, and their
           numeric identifiers are chosen in the SYS_UID_MIN-SYS_UID_MAX range, defined in
           /etc/login.defs, instead of UID_MIN-UID_MAX (and their GID counterparts for the
           creation of groups).

           Note that useradd will not create a home directory for such an user, regardless of the
           default setting in /etc/login.defs (CREATE_HOME). You have to specify the -m options
           if you want a home directory for a system account to be created.

Launchpad Janitor (janitor) wrote :

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

Changed in accountsservice (Ubuntu):
status: New → Confirmed
Changed in lightdm (Ubuntu):
status: New → Confirmed

The suggestion was made to add a accountsservice file for it like:
echo -e "[User]\nSystemAccount=true" > /var/lib/AccountsService/users/libvirt-qemu

I agree this might be an option - and I might even be forced to take it at some point, but then I ask myself for how many extra Desktop envs/services would we make extra files if more are found.
Do we really want to make this a custom change in all those packages (and any else in the future who add system users).
- OR -
Wouldn't it make much much more sense to make accountsservice realize on non login shells as all other logins seem to do (e.g. sddm) and as itself did in the past (hidden-shells)?

After some IRC discussions I'm increasing prio in accountsservice as more people are convinced this is the place to fix it and it seems to get a rise in "popularity".

Changed in accountsservice (Ubuntu):
importance: Undecided → High
ali salama (alisalama) on 2017-04-26
Changed in libvirt (Ubuntu):
assignee: nobody → ali salama (alisalama)

Hi Ali,
as I outlined before the fix likely has to take place in accountsservice not in libvirt.
You assigned yourself, so I wanted to ask what you have in mind to do?

In case this was an accident you might want to unassign yourself, but "subscribe" [1] you to the bug to stay up to date on this - you find the box to do so to the right of the bug launchpad page.

[1]: https://help.launchpad.net/Bugs/Subscriptions

Changed in sddm:
importance: Unknown → Undecided
status: Unknown → New
affects: sddm → sddm (Ubuntu)
Changed in sddm (Ubuntu):
importance: Undecided → Unknown
status: New → Unknown
status: Unknown → Invalid

Note to SDDM users:
They won't fix it.
You may want to manually tweak /etc/sddm.conf
For example I changed it to
[Users]
MaximumUid=2000
MinimumUid=1000

So my users are all present and QEMU with UID 64055 has been cut out.

Changed in sddm (Ubuntu):
status: Invalid → Fix Released
Gabriel Cotnoir (gcotnoir) wrote :

Note to lightdm users
You can manually tweak /etc/lightdm/users.conf
Add libvirt-qemu to the hidden-users

pierre (dubiaj) wrote :

Thanks gcotnoir, it's a nice workaround while the bug gets looked into.

KDE and Gnome seem to not have the issue in general (To admit - I didn't try myself the Gnome case yet), so in Artful it might be resolved by the switch to Gnome.
I didn't hear from the Desktop Team yet about accountsservice getting a fix.

Also for now there is a workaround in [1]
If this gets no attention for a (more correct and preferred general solution by the desktop Team) we might add that in a libvirt update, but as it is a symptomatic fix only I'd prefer the other solution.
And in turn all the affected packages would have to get such a fix (probably even more and in general as users could add "hidden-shell" type users on their own - and those shouldn't be displayed as well.

[1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1667113/comments/18

Madan Hegde (madan.hegde) wrote :

I had been facing the same problem along with one more user account named "No value has been set".
For "Libvirt Qemu" tried purging "qemu-kvm" and it's configuration files. But still user account was existed. I had been trying for the solution and found one that you can also try. (I'm using linux mint 18.2 Sonya)

Go to location /etc/ as root and find a file named "passwd" and open it. Now find the line
"libvirt-qemu:x:64055:132:Libvirt Qemu,,,:/var/lib/libvirt:/bin/false" (see the image I attached not to get confused, values may vary in your case) and clear it (don't clear any other line which is not related to "libvirt-qemu"). I found that line almost at the end of the list.

If you're having one more user account named "No value has been set" then clear the line below:
"<admin name>:x:1001:1002:No value has been set:/dev/null:/dev/null" (values may vary in your case)

And now I don't have these user accounts or any other issue after removing those values: "libvirt qemu" and "No value has been set"

The attachment "IMG_20170914_192319.jpg" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Tom Reynolds (tomreyn) on 2017-09-14
tags: added: trusty
removed: patch
Changed in libvirt (Ubuntu):
assignee: ali salama (alisalama) → nobody
Tom Reynolds (tomreyn) wrote :

This is apparently a bug, more precisely a regression (#8) in either Ubuntu's accountservice or lightdm.
This also affects trusty (as I have tested), so adding tag.
There is no patch, yet, removing tag (set in #21), renaming image in #21.
~alisalama has not handled this bug since April, I assume it is not a person, so removing assignment.
Hopefully ~ubuntu-desktop can take a look at this bug sooner or later.

Thanks Tom, I agree that loosing the hidden-shells seems to be a regression.
And to make the state more clear that this in the current state is considered a an issue of accountservice or lightdm lets mark the other packages won't fix for now. Otherwise everybody assumes "the other will do it".

This give a better overview and in general it isn't feasible to fix "all-those" and since there can be high-id system-users added manually by users the issue would still persist even when all those other packages would be fixed.

Changed in netqmail (Ubuntu):
status: Confirmed → Won't Fix
Changed in libvirt (Ubuntu):
status: Confirmed → Won't Fix
Changed in ifmail (Ubuntu):
status: Confirmed → Won't Fix
Changed in ceph (Ubuntu):
status: Confirmed → Won't Fix
spike speigel (frail-knight) wrote :

Is this the same issue as bug #857651 ??

@Spiegel - yes I think so, thanks for finding the old reference.
Marking as a Dup.

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

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.

Arrr wanted to send that update to the dup target ...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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